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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 625551B356D for <>; Tue, 2 Jun 2015 23:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 OupZWnLxYbGJ for <>; Tue, 2 Jun 2015 23:00:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E13541B3564 for <>; Tue, 2 Jun 2015 23:00:34 -0700 (PDT)
Received: by obbea3 with SMTP id ea3so4651640obb.0 for <>; Tue, 02 Jun 2015 23:00:34 -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=yAIMpXyaXuP/EwOrAs52VZ2EArPQSwNzc3owl+eGbL8=; b=xW6FnwfpmiVUdkfJtuzNqlcocPOMbr1Wf0HnlZYMLRdDCd6CtmeJu7pBfUaAhSHuna /1LQQhrRj6wY7DtFWwoc1KB5gzIArth2W/uN9Q+DtNmnUo8Ih3JiKUKBnY4mG8uJKaFP dp0YU/VZuRMyV3bQ+v/SJCUmiz75+qTGL3bVPljYMgcGvRfs//w5GbmQrTg1sqp5ZSx8 A8xPCTI0l+at9CZ1ydbeV0nR95vk1NjiYAOuPNlzhYxrKUKDvk9s81owJejvr5ZFA+NR K86DSeGo48V8JAlBusfYW6S7BmQ4gV/+r6N4gD77nyLE8TwzJwp9W9TWrlYfEtHIzxk4 O09w==
X-Received: by with SMTP id 188mr23947248oib.13.1433311234393; Tue, 02 Jun 2015 23:00:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 Jun 2015 23:00:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Tony Arcieri <>
Date: Tue, 2 Jun 2015 23:00:14 -0700
Message-ID: <>
To: Hubert Kario <>
Content-Type: multipart/alternative; boundary=001a1137c6b6fa8d2c051796c62a
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:00:37 -0000

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

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

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