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

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2015-06-03 13:23:36 -0400, Dave Garrett wrote:
> On Wednesday, June 03, 2015 04:20:15 am Tony Arcieri wrote:
>> On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <[e-mail]> wrote:
>> > Well... here's a way it could:
>> > 1) Deprecate/prohibit all "DH(E)_*" cipher suites
>> 
>> I'm a bit unclear on this, but I think that's actually happening as part of TLS 1.3?
>
> No, that's what you're proposing with a diediedie. (seems to have been a miscommunication here)
>
> DH_* (non-ephemeral) are being deprecated in TLS 1.3. DHE_* are still
> in TLS 1.3. You're argument is that non-ECC DH(E) is harmful because
> Java is crap and chokes on it. (yeah, Java should be fixed, but it is
> crap and out there and breaking, and getting rid of DH(E) would fix
> that)
>
> What I said was:
>> 1) Deprecate/prohibit all "DH(E)_*" cipher suites
>> 2) Create a new set of "FFDHE_*" cipher suites to replace them that only allow strong groups (3072+)
>
> 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.
>
> It's a cake-and-eat-it-too suggestion. Kill old DH(E) and replace it
> with a limited set of new suites that are only usable with strong
> groups and only supported by new clients.

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).


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.

Regards,

          --dkg

[0] e.g. see Message-ID: 20131107213744.GQ18713@localhost on this
    mailing list, "Windows 2003 TLS 64 ciphersuite limit" from Nico
    Williams, 2013-11-07