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

[Tony Arcieri <[e-mail]>]

On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario <[e-mail]> wrote:

> as it was pointed out many times: adding support for this extension and
> groups
> to implementations that already support FF DHE is rather trivial, adding
> support for ECC is complex (both because of compexity of ECC and because
> it's
> a completely new set of algorithms)
>
> This allows us to move away from defaulting to 1024bit or 2048bit on server
> side in fear of breaking, for example, Java based clients
>

Hi there,

Some context. I typically don't go "full blowhard". That's something I
actively avoid. But I feel it's warranted here.

I am responsible for the external ciphersuites configuration for a site
that moves over a hundred million dollars per day supporting millions of
users.

I have also spent what I feel are undue amounts of my own time (probably at
least 10 hours in the past month) chasing down DHE problems with Java
stacks, trying to solve problems where entire language ecosystems had a
total outage of their packaging systems due to Java DHE issues.

My opinion is DHE diediedie. I am sorry if I didn't participate when it was
"pointed out many times". But this is a draft, and I feel like now isn't an
undue time to make a counterargument?

Even having DHE enabled when 4096-bit DHE ciphersuites are configured
completely blocks Java from completing a TLS handshake. Depending on what
Java version, having 2048-bit DHE ciphersuites enabled does the same thing.

There were two solutions: get the upstream service to eliminate the
problematic ciphersuites, or have the Java client disable DHE. In hopes of
getting traffic flowing again, I have told both sides to shut off DHE, and
as soon as either side complied, the handshake could complete.

What problem do you think this draft is solving? How will it fix older Java
clients?

So far my experience has been that shutting off DHE solves the problem. If
you want ECC, use BouncyCastle as your JCE provider.

Anyway, I am responsible for supporting legacy Java 7 (and Java 6!) clients
and my opinion is that DHE is actively detrimental to the TLS ecosystem,
*especially* where Java is involved.

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.

-- 
Tony Arcieri