Re: [TLS] Downgrade protection, fallbacks, and server time
David Benjamin <davidben@chromium.org> Thu, 02 June 2016 14:50 UTC
Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C8F12D0F1 for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 07:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 NIB6XcZBfZEQ for <tls@ietfa.amsl.com>; Thu, 2 Jun 2016 07:50:03 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 07E2C12D0ED for <tls@ietf.org>; Thu, 2 Jun 2016 07:50:03 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id e62so127584128ita.1 for <tls@ietf.org>; Thu, 02 Jun 2016 07:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LaJEhWgJf5wc2tXz7bVGm29QBUxxA4fOXRzwd2vn5Ow=; b=U6mD8JMnyY+s/D+m+EznKmre68wGJK67Er1Y0o7bpmSo6K3Baj4EJVPVy+1XUPREGL RenMJxd3CUHI19FjRnyJtuG6oJfEde8tOWboRN8VPyh54oruV1xCZeh2GLad0i8worsY l1R6lgKY2Wl38akbNlZANqzXpkcRMK3Zkn2CQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LaJEhWgJf5wc2tXz7bVGm29QBUxxA4fOXRzwd2vn5Ow=; b=D1qyLpiRYayzVfwOQ3ppbRaeAySFngme0/hBzdUx5qzXdpComxwLmB8KQy+HAqoalI VNd+aNey0eTwwJdooiyY0KSw6Ad3rStNXcFdfxqr9mkRABMHLmyBhcuBVHGMFmFoCMfP MLcvXFVvLBQD5NMxRF5QA5HetZTt3RsIi9lTsAKWLCDDVLP4aovyTd7WEJO4gD8FQ1BM vPdyMpTI0qmUsq7puDQHMla5MClB7hJLxsiIXjfMcfvUllC13B5Bb8z+3qM48h67Rr8m 7ATy6tztR5VxtYO4WWl/ncrHbJ837V6MOvzaJsFFi1ZyyFZLh9ad9nsSiN0biuQrPV/g mdvg==
X-Gm-Message-State: ALyK8tI0O5cFeceGIpKLeUWaxk7y/PwYUVhLvgSW8kB2+4p4HS40qX1JkfSLZO2iuJvL82ll6f4VGGY3e74nbxRT
X-Received: by 10.36.61.202 with SMTP id n193mr4168649itn.92.1464879002124; Thu, 02 Jun 2016 07:50:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8qwaDuGyHOu_4kpWN+c+vJKXyERPJu-2xR+nu=sPzG5vZ+ag@mail.gmail.com> <6238043.DCePXUsCVt@pintsize.usersys.redhat.com>
In-Reply-To: <6238043.DCePXUsCVt@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 02 Jun 2016 14:49:52 +0000
Message-ID: <CAF8qwaCx-AyconwmB+mXMtNFYxhRrt7Kkqw+x5xZUgajXw1ZkQ@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1145bb4690088905344cb838"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/X4t0O4NHTX1-ZF9WBlivVxZ95-w>
Subject: Re: [TLS] Downgrade protection, fallbacks, and server time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 02 Jun 2016 14:50:05 -0000
On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario <hkario@redhat.com> wrote: > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > > In case folks hoped we could bump the ClientHello version without > > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance > > very much exists. (Maybe we should just give up on > > ClientHello.version and use an extension? Extensions have rusted > > less.) > > > > I picked a large list of top sites and tried connecting to them. Just > > under 2% of them could handle a TLS 1.2 ClientHello, but not the same > > ClientHello with the version switched to 1.3 (no other changes, so I > > haven't tested a real 1.3 ClientHello). They're not unknown hosts > > either. I expect if you probe any top site list, you'll very quickly > > find some. > > there are also servers which choke on large extensions (say 4096 bit DH > client key share with 384 bit ECDH key share), so avoiding the bump in > version number won't solve all the problems either... > TLS 1.3 doesn't require clients offer a KeyShare for all groups in the first ClientHello. It costs a HelloRetryRequest and another round-trip, but I think that's fine. Clients can limit FFDHE in the initial ClientHello to servers they've spoken to before or something. For unknown servers, if you only predict a couple of EC groups, it shouldn't blow it up too badly, but of course we'll just have to see. (Or clients can just not bother with FFDHE to begin with. I don't see the point and am not very interested in implementing it at all.) > Speaking of version number, does the text say that a server _MUST_ > accept any version higher than the one that is specified in the RFC, but > reply with 0x03,0x04 in case it doesn't support any future version of > the protocol? It would be nice to have some kind of stick for the broken > implementations... > I'm not sure I follow. The specification certainly spells out how version negotiation is supposed to work. That hasn't stopped servers from getting it wrong. Fundamentally this is the sort of thing where bugs don't get noticed until we make a new TLS version, and we don't do that often enough to keep rust from gathering. David
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Martin Rex
- [TLS] Downgrade protection, fallbacks, and server… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Eric Rescorla
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Eric Rescorla
- Re: [TLS] Downgrade protection, fallbacks, and se… Martin Thomson
- [TLS] no fallbacks please [was: Downgrade protect… Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Yoav Nir
- Re: [TLS] Downgrade protection, fallbacks, and se… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] Downgrade protection, fallbacks, and se… David Benjamin
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] Downgrade protection, fallbacks, and se… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… Martin Thomson
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Ilari Liusvaara
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Xiaoyin Liu
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] no fallbacks please [was: Downgrade pro… Eric Rescorla
- Re: [TLS] no fallbacks please [was: Downgrade pro… Andrei Popov
- Re: [TLS] no fallbacks please [was: Downgrade pro… Eric Rescorla
- Re: [TLS] no fallbacks please [was: Downgrade pro… Viktor Dukhovni
- Re: [TLS] no fallbacks please [was: Downgrade pro… David Benjamin
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Bill Frantz
- Re: [TLS] Downgrade protection, fallbacks, and se… Yaron Sheffer
- Re: [TLS] Downgrade protection, fallbacks, and se… Stefan Winter
- Re: [TLS] no fallbacks please [was: Downgrade pro… Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] no fallbacks please [was: Downgrade pro… Dave Garrett
- Re: [TLS] no fallbacks please [was: Downgrade pro… Jeffrey Walton
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Peter Gutmann
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Kyle Rose
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Salz, Rich
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yoav Nir
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … David Benjamin
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Andrei Popov
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Yuhong Bao
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Dave Garrett
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Hubert Kario
- Re: [TLS] [FORGED] Re: no fallbacks please [was: … Nikos Mavrogiannopoulos
- Re: [TLS] no fallbacks please [was: Downgrade pro… Tony Arcieri