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

[Dave Garrett <[e-mail]>]

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.


Dave