Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt

[Dave Garrett <[e-mail]>]

On Wednesday, June 03, 2015 01:48:39 pm Daniel Kahn Gillmor wrote:
> On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote:
> > My suggestion is to do exactly what you propose, publish a DH(E)
> > diediedie, but in the same RFC standardize a new set of DHE cipher
> > suites with strong requirements using a new prefix (e.g. FFDHE) and
> > new codepoint assignments. Servers supporting these new suites will
> > never negotiate them with old clients that don't support them, but
> > newer clients that add support will be able to negotiate DHE using the
> > new cipher suites.
> 
> Alternately, we can get the same functionality with the
> negotiated-ff-dhe draft:
> 
>  * servers compatible with the draft can choose to never negotiate ffdhe
>    with clients that don't advertise support.
> 
>  * newer client will be able to negotiate ffdhe with these servers by
>    advertising support.
> 
> The main difference depends on what newer clients want old servers to do:
> 
>    If clients are willing for old servers to go ahead and negotiate
>    FFDHE ciphersuites even if their parameters might be dubious, then in
>    your proposal they need to offer both sets of ciphersuites (possibly
>    increasing the list of ciphersuites beyond 64, which may tickle other
>    bugs [0])   
> 
>    If clients want old servers to never negotiate an FFDHE ciphersuite
>    unless they're offering good parameters, then under your proposal
>    they simply offer the new ciphersuites.  Under the current
>    negotiated-ff-dhe draft, a client receiving bad parameters from the
>    server has to abort a connection (and can subsequently re-try without
>    listing any FFDHE ciphersuites if it wants).

Yes, exactly.

> For TLS 1.3, i'm expecting that any FFDHE ciphersuites will have a
> radically different handshake, so very little of this is relevant (plus,
> it will be TLS 1.3, so we can treat the existing ciphersuites
> differently based on the version of the protocol in use).  So the
> negotiated-ff-dhe draft aimed for the simplest, most minimal change for
> 1.2 and earlier.

The topic brought up by Tony Arcieri was the apparent plague of old Java clients using TLS currently. A replacement set of cipher suites would transparently fix this in a simpler way. It adds more suites, yes, but it would ensure that this is only ever even _attempted_ to be negotiated between clients and servers that both support them properly.

A replacement set of FFDHE cipher suites would also be useful to more clearly segregate the clients and servers that support strong FFDHE from those that support weak parameters. A server supported suites scan would very clearly show the capabilities without having to check the extension for more detail. Even if this could all be technically implemented without new suite names/codepoints, doing so could be safer to manage and a bit more mistake-resistant.


Dave