On Monday 06 February 2017 20:18:48 Andreas Bartelt wrote: > Yes, right - thanks. I wasn't aware that this is actually a MUST > requirement from RFC 4492. I'm quite surprised that the "Supported > Elliptic Curves Extension" is also used in order to specify any allowed > curves for use in the context of certificates. I think this is quite > inconsistent but it's what this RFC seems to mandate. It's inconsistent > because there is no such binding with regard to -ECDHE-RSA- or -DHE-RSA- > cipher suites.
Both DHE and RSA are either supported or they are not. If they are not then the client should not include cipher suites that use these key exchange and/or authentication methods. ECDHE and ECDSA are somewhat different, the main reason being the use of named curves vs arbitrary curves. If named curves were not in use then more data has to be provided in the Server Key Exchange and it is more like a DHE key exchange (see RFC 4492 section 5.4 for more details if you're interested). The trade off is effectively providing EC parameters to the client versus requiring the client and server to support the same named curves. > I've successfully tested a P-384-based certificate which allowed me to > explicitly specify -groups secp384r1 for ECDHE on the client side. Excellent. > I think it would be beneficial to allow to explicitly specify multiple > groups with the ecdhe statement in httpd.conf, and also to respect their > order. Absolutely - as noted in an earlier reply, this is what is planned.
