Timothy Jackson: > 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 > > There are good reasons to combine AES256 with ECDHE on the P256 curve.
Please read https://blog.cr.yp.to/20151120-batchattacks.html "Bottom line: 128-bit AES keys are not comparable in security to 255-bit elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe? Unclear." There is also the paper "Understanding brute force" from Daniel J. Bernstein. https://cr.yp.to/papers.html#bruteforce > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
