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

[Tony Arcieri <[e-mail]>]

Here is what I've observed:

Logjam made a lot of people aware of the problem of weak D-H groups.
Because of that, people have been trying to enable stronger D-H groups.

Unfortunately, exactly as you've pointed out, legacy clients are
incompatible with these stronger D-H groups. For legacy Java clients, it
catastrophically completely prevents the TLS handshake from succeeding if
any such ciphersuite is even present in the ServerHello.

My experience has been, and correct me if I'm wrong, that the only two ways
to fix this are for the Java client to disable all DHE ciphersuites, or for
the server to not offer them. Depend on the Java version, DHE with 2048-bit
keys can break it, and for newer versions of Java, the problem persists for
4096-bit DHE.

The result I've seen has been people hardening their DH groups in response
to Logjam, and inadvertently breaking Java clients... for more than one
entire language ecosystem temporarily.



On Tue, Jun 2, 2015 at 11:00 PM, Tony Arcieri <[e-mail]> wrote:

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



-- 
Tony Arcieri