On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson <tjack...@mobileiron.com> wrote:
> 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. > Off the top of my head, this rule seems like it would have several quite negative side effects: - It would require you to use Curve448 or P521 with ChaCha/Poly1305 (256-bit key) but allow you to use Curve25519 with AES-GCM 128, which cuts against one of the major reasons to use ChaCha/Poly1305, namely that it's faster on mobile platforms. - It would essentially preclude using RSA certificates with ECC at all, because the RSA modulus you need to match 256-bit ECC is impractically large. It's also worth noting that AES-GCM 256 and 128 use the same authentication tag size. -Ekr > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
