IETF Logo Mail Archive

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

Yuhong Bao <yuhongbao_386@hotmail.com> Wed, 03 June 2015 06:54 UTC

Return-Path: <yuhongbao_386@hotmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE71B35E6 for <tls@ietfa.amsl.com>; Tue, 2 Jun 2015 23:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.66
X-Spam-Level:
X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqyIKXaHB--t for <tls@ietfa.amsl.com>; Tue, 2 Jun 2015 23:54:52 -0700 (PDT)
Received: from BLU004-OMC2S5.hotmail.com (blu004-omc2s5.hotmail.com [65.55.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5060A1B35D6 for <tls@ietf.org>; Tue, 2 Jun 2015 23:54:52 -0700 (PDT)
Received: from BLU177-W1 ([65.55.111.71]) by BLU004-OMC2S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 2 Jun 2015 23:54:51 -0700
X-TMN: [sOYE/sM98Z8LtlkiTVsume11ri+nNqDt]
X-Originating-Email: [yuhongbao_386@hotmail.com]
Message-ID: <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl>
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: Tony Arcieri <bascule@gmail.com>
Date: Tue, 02 Jun 2015 23:54:50 -0700
Importance: Normal
In-Reply-To: <CAHOTMVLpmS94cBZOxu6e3-e2MMO+Z0SAvPb7dWW47jQqXpT9+A@mail.gmail.com>
References: <20150601225057.17500.96911.idtracker@ietfa.amsl.com>, <CAHOTMVJ1xu+mEaROWKuEtW1E8Ks3r3gKagEM9mJdBOKW3kSZJQ@mail.gmail.com>, <1474500.r0W7gM0pAO@pintsize.usersys.redhat.com> <CAHOTMVJgqqRBYWR+8LtwxfdRVWxEXLZAgzr5Q-1DH7ejONAGnw@mail.gmail.com>, <m2lhg1b8us.fsf@localhost.localdomain> <CAHOTMVLrgUNi449DQwggt556ioEeXCQTUN+M3phBftPk88xtOw@mail.gmail.com>, <BLU177-W17E87DB68F54CE64BDC44C3B40@phx.gbl>, <CAHOTMVLpmS94cBZOxu6e3-e2MMO+Z0SAvPb7dWW47jQqXpT9+A@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jun 2015 06:54:51.0110 (UTC) FILETIME=[302F3860:01D09DCA]
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/H5UgJ16nKN5_uPCXBTl-fWavRdI>
Cc: Geoffrey Keating <geoffk@geoffk.org>, TLS WG <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2015 06:54:53 -0000

The idea is that the server can send a different weaker DHE key in the ServerKeyExchange, or not use DHE suites at all.

________________________________
> From: bascule@gmail.com 
> Date: Tue, 2 Jun 2015 23:52:36 -0700 
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt 
> To: yuhongbao_386@hotmail.com 
> CC: geoffk@geoffk.org; tls@ietf.org 
> 
> Yes sorry I meant ClientKeyExchange... 
> 
> But can you explain to me how this solves the problem for legacy clients? 
> 
> On Tue, Jun 2, 2015 at 11:52 PM, Yuhong Bao 
> <yuhongbao_386@hotmail.com<mailto:yuhongbao_386@hotmail.com>> wrote: 
> The client don't receive the ServerKeyExchange message containing the 
> DHE key at all until after they sent the ClientHello. 
> 
> ________________________________ 
>> From: bascule@gmail.com<mailto:bascule@gmail.com> 
>> Date: Tue, 2 Jun 2015 23:35:46 -0700 
>> To: geoffk@geoffk.org<mailto:geoffk@geoffk.org> 
>> CC: tls@ietf.org<mailto:tls@ietf.org> 
>> Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-10.txt 
>> 
>> On Tue, Jun 2, 2015 at 11:32 PM, Geoffrey Keating 
>> 
> <geoffk@geoffk.org<mailto:geoffk@geoffk.org><mailto:geoffk@geoffk.org<mailto:geoffk@geoffk.org>>> 
> wrote: 
>> It's covered in section 4: 
>> 
>> If at least one FFDHE ciphersuite is present in the client 
>> ciphersuite list, and the Supported Groups extension is either absent 
>> from the ClientHello 
>> 
>> Unless I'm mistaken, unless you configure the 
>> jdk.tls.disabledAlgorithms property explicitly (with e.g. "DHE keySize 
>>> 2048"), Java clients are aborting *before* they send the ClientHello. 
>> Please let me know if you're seeing otherwise. I could be mistaken and 
>> perhaps there's a server-side workaround for this that isn't "disable 
>> all DHE ciphersuites". But this is what I've personally observed and 
>> have been advising people about. 
>> 
>> I'm not saying it can't be fixed with additional 
>> configuration/errata/etc, I'm arguing that it's *breaking clients in 
>> the field right now* 
>> 
>> tl;dr: I am seeing *widespread TLS breakages* because of this resulting 
>> in *huge outages* for Java clients 
>> 
>> -- 
>> Tony Arcieri 
>> 
>> _______________________________________________ TLS mailing list 
>> TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls 
> 
> 
> 
> 
> -- 
> Tony Arcieri

v2.23.0 | Report a Bug | By Email