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

Yuhong Bao <> Wed, 03 June 2015 06:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D97531B3581 for <>; Tue, 2 Jun 2015 23:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HZC1xXKJcuGI for <>; Tue, 2 Jun 2015 23:15:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBDC51B3586 for <>; Tue, 2 Jun 2015 23:15:18 -0700 (PDT)
Received: from BLU177-W42 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Jun 2015 23:15:18 -0700
X-TMN: [2siJtrRqD9AL8pYaRwqiGaZx2+7EI9aq]
X-Originating-Email: []
Message-ID: <BLU177-W426F8D4CBC7EC6D013817DC3B40@phx.gbl>
From: Yuhong Bao <>
To: Tony Arcieri <>, Hubert Kario <>
Date: Tue, 2 Jun 2015 23:15:17 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jun 2015 06:15:18.0326 (UTC) FILETIME=[A9E51D60:01D09DC4]
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:15:21 -0000

These older versions of Java don't support FF-DHE, and the server can send a different weaker DHE key to older clients.

> From: 
> Date: Tue, 2 Jun 2015 23:00:14 -0700 
> To: 
> CC: 
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt 
> 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 
> _______________________________________________ TLS mailing list