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

[Tony Arcieri <[e-mail]>]

On Wed, Jun 3, 2015 at 1:05 AM, Dave Garrett <[e-mail]> wrote:

> People want a backup to deal with mistrust of ECC curves and general
> paranoia.


I'll refer to my first response to this thread:

On Mon, Jun 1, 2015 at 4:02 PM, Tony Arcieri <[e-mail]> wrote:

> I expect the response is going to be "What if there's some catastrophic
> failure of ECC?"
>

The reality is DHE hardening attempts are breaking Java 6, 7, and in some
cases 8 clients from negotiating TLS connections in the field right now,
today. To me that's worse than an ECC failure. I'll go out on a limb and
say that "it doesn't work" is a worse problem than "it's insecure".

Java 7 and 8 clients can negotiate ECDHE instead of DHE, so what we're
seeing here is legacy cruft preventing the use of an otherwise semi-modern
configuration (for relative values of modern). If we simply shut the cruft
off, everything is great, and the handshake succeeds using a key exchange
facilitated by modern algorithms. I feel like I'm dealing with legacy knobs
that nobody in their right mind would turn, but simply by existing are
breaking the entire TLS communication channel from being established.

Java 6 can't negotiate DHE with a "secure" key size. The best it can do is
1024-bit. Both Java 6 and 7 are already EOL so there's little chance of
IETF drafts affecting them unless there's a server-side workaround that
isn't "shut off DHE".

Has someone actually implemented what's described in this draft and shown
it allows legacy Java clients to negotiate a secure DHE handshake? And even
if that's the case, why care about DHE instead of moving clients to ECDHE?

Who is this draft actually helping?

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?

-- 
Tony Arcieri