On 02/07/17 12:32, Joel Sing wrote:
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 guess that's not what I meant. I'm fine with the use of named curves.
The same goes for named FFDHE groups, i.e., RFC 7919 makes the use of
DHE much less error prone than before.
What I find suboptimal in RFC 4492 is that named curves, which are
provided with the "Supported Elliptic Curves Extension", specify the
allowed primitives for ECDHE _and_ for ECDSA (i.e., signatures) at the
same time. In my opinion, it would have been better to be able to
specify them independently - e.g., by having two separate extensions, or
at least distinct standardized values for use of curves in ECDHE and
ECDSA. I've also found this:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-11 . It's due to
other reasons, but at least eddsa_ed25519 will be distinct from ecdh_x25519.
