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

[Geoffrey Keating <[e-mail]>]

Tony Arcieri <[e-mail]> writes:

> So I am very, very, very confused about what argument you're trying to make
> about Java here. As far as I'm concerned the *only* workable solution for
> older Java clients is to shut DHE off.
> 
> Can you please explain to me where in this draft I can locate the part
> about how it will help older Java clients better participate in the TLS
> ecosystem, because I can't find it.

It's covered in section 4:

   If at least one FFDHE ciphersuite is present in the client
   ciphersuite list, and the Supported Groups extension is either absent
   from the ClientHello entirely or contains no FFDHE groups (i.e. no
   codepoints between 256 and 511 inclusive), then the server knows that
   the client is not compatible with this document.  In this scenario, a
   server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE
   ciphersuite and offer an FFDHE group of its choice to the client as
   part of a traditional ServerKeyExchange.

In this case, and I think most of the time, a server should choose the
first of the two MAYs: offer a non-FFDHE ciphersuite.  This has the
effect of shutting FFDHE off for those older clients but allows you to
continue to offer stronger FFDHE to newer clients (if they for some
reason won't do ECDHE).

The old-client compatibility story with this draft is quite strong.
Alas the old-server compatibility story is not so strong; a new client
with an old server might get proposed an insecurely small FFDHE field,
and have to reject it and reconnect.