I’ve noted that many (most?) TLS implementations choose their ECDHE curves seemingly without regard to the cipher suite strength. Thus, they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key on the P256 curve. This seems odd to me, since the P256 curve obviously has a lower security strength than AES256. This seems important issue to resolve because most products (and even TLS libraries) do not allow the administrator to configure the available ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly undermining the security of your TLS connection.
Is this an intentional choice by this group for some reason that I haven’t realized yet? How would this group feel about a proposal to address this by specifying in the 1.3 specification that implementations must ensure that the strength of the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? Perhaps an equivalency rule for the MAC might also be in order? Apologies if this is already resolved somewhere in the draft RFC. I looked but didn’t find it. For what it’s worth, I’ve noticed OpenSSL and other implementations trying to address this by creating a “Suite B Mode”, but that seems to address a specific case but leave the generic case unresolved. Cheers, Tim
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
