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

Tony Arcieri <> Wed, 03 June 2015 06:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2AE5B1B3584 for <>; Tue, 2 Jun 2015 23:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SxxNZ-xUYELy for <>; Tue, 2 Jun 2015 23:17:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 849F31B3569 for <>; Tue, 2 Jun 2015 23:17:11 -0700 (PDT)
Received: by obbea3 with SMTP id ea3so175494obb.0 for <>; Tue, 02 Jun 2015 23:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9EOWWXo1KSy70q3r+YuW5AR4LqIMQ7ruepdAExg+Rh0=; b=OgrjC+OQeDDQYpylVw1Mgy2yaSq1a7k8UETNTeZn213KfldZ6uBHG3oXSEuh73I+Su lYa9L2Q6rrM658AWgPrYwxmGwrO0a9otcGtCCHnyAqjnmUZIhxnbyvI9kfONjGos5CaR hi9bFZIWzIO5jnXCXMI4PY1oXcpUdHTzNk9kw95Dk5UwzrdGLyyvhK1chI58eKTyMpX4 mQOOp1cf1RVO9qJ5T+Q+URkM8sUgtcaz9nqLzT0Q3pyIOT2iAcya7r+92xcUXr6GV8td HNHsOTNGCe6Qt+99cSfHKaITr64A7atxabvT3PTbffXdaW30G9tZEwe/nfgN2m9kCTog HIHw==
X-Received: by with SMTP id fk2mr26255813obb.35.1433312231091; Tue, 02 Jun 2015 23:17:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Jun 2015 23:16:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Tony Arcieri <>
Date: Tue, 2 Jun 2015 23:16:50 -0700
Message-ID: <>
To: Hubert Kario <>
Content-Type: multipart/alternative; boundary=089e013a042062f69a0517970293
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jun 2015 06:17:14 -0000

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

> On Tue, Jun 2, 2015 at 5:54 AM, Hubert Kario <> 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