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

Tony Arcieri <bascule@gmail.com> Wed, 03 June 2015 07:00 UTC

Return-Path: <bascule@gmail.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 9D7B71A6FF9 for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 00:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 4d97LaHOYI3u for <tls@ietfa.amsl.com>; Wed, 3 Jun 2015 00:00:28 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5BC1A1AA9 for <tls@ietf.org>; Wed, 3 Jun 2015 00:00:28 -0700 (PDT)
Received: by objn8 with SMTP id n8so725669obj.3 for <tls@ietf.org>; Wed, 03 Jun 2015 00:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xl6Z9VT7R7k5Q5JT0dg3c3Xn61aWFHfSQ87h/J92twE=; b=gbdT5hbokYlqpc5Oe3Mk5rQnexeHClHWm3oQsZQFO8Z3DLFPaKzNypFCCCu7VqNH+w G1u6FSyPzTDLTss7/uirbUKOKtZDGHNKhcdSAEJt45KlqWNhEP2K/Rjo0ckNayg8FQCw az/4o/cZK0JUuhrxLGNye+27hpkmPVgh78zwVJABQf7UAhxbXnMriM+NQxdhFjgvQ8LC 9PFAcRA3vgvGODQC2n/ruuj5+qo22Sq7so5P0IemwLOd4z0XKMWHtghPEnsYv28s6UaS ckqmf6QFHq02Y0clPTjJ5qzM5hWm7tUVOuOjwdOmah72QEucKdbxVIT8yOInj+E75ty7 5iwg==
X-Received: by 10.202.210.80 with SMTP id j77mr24526680oig.68.1433314827973; Wed, 03 Jun 2015 00:00:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.110.241 with HTTP; Wed, 3 Jun 2015 00:00:07 -0700 (PDT)
In-Reply-To: <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl>
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> <BLU177-W1EA1B34A70F648FD8C139C3B40@phx.gbl>
From: Tony Arcieri <bascule@gmail.com>
Date: Wed, 3 Jun 2015 00:00:07 -0700
Message-ID: <CAHOTMV+FxxG7tpq55UyKs+q06uk5H-dCqkTswBDJsM=5Bv6pqA@mail.gmail.com>
To: Yuhong Bao <yuhongbao_386@hotmail.com>
Content-Type: multipart/alternative; boundary=001a113d26562c3e0d0517979d94
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BIplxRc8_QDaLWVr8Z-djULYUZQ>
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 07:00:30 -0000

So this is the exact problem I've been talking about.

After this draft is actually implemented in all TLS servers everywhere,
server operators can add Java-specific errata to their configuration to
work around the fundamental problem that DHE is breaking Java TLS
handshakes.

Or you can just add the Java property I cited above. Which is total oddball
errata. Nobody should have to worry about jdk.tls.disabledAlgorithms="DHE
keySize > 2048"

This is just adding to the "headache" of maintaining a modern TLS stack.

I'll freely admit I just made mistakes trying to diagnose this problem but
as a practitioner I seriously don't care about supporting these things and
want them to just go away and for TLS handshakes to just work and not
spontaneously break because of misconfigurations.

I don't see how adding more complexity fixes the problem.

I just want DHE to diediedie.

Perhaps someone can explain how keeping DHE around is actually beneficial
in any way whatsover? Right now it's just giving me a headache and making
me angry.


On Tue, Jun 2, 2015 at 11:54 PM, Yuhong Bao <yuhongbao_386@hotmail.com>
wrote:

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




-- 
Tony Arcieri