On Wednesday 23 March 2016 00:38:13 Timothy Jackson 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.
In my experience, many (12%) servers simply ignore the list of curves advertised by client and use the P-256 curve always. Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 is not advertised. > Is this an intentional choice by this group for some reason that I > haven’t realized yet? IMHO, it's just a result of limitation in the libraries - i.e. closer to "a bug" than "design choice" > 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. Recommendation? maybe. Requirement? unneeded if not harmful, for the points already raised > 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. Only the new OpenSSL actually can use more than one curve on the server side... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
