Re: [TLS] consensus on backwards compatibility changes
Joseph Salowey <joe@salowey.net> Tue, 27 January 2015 22:45 UTC
Return-Path: <joe@salowey.net>
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 D06461A701F for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 14:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 xsQvJSKjco49 for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 14:45:49 -0800 (PST)
Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD011A6F33 for <tls@ietf.org>; Tue, 27 Jan 2015 14:45:48 -0800 (PST)
Received: by mail-qg0-f44.google.com with SMTP id l89so14137347qgf.3 for <tls@ietf.org>; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cejkRA6s41G15b+PHnaIMBHZ0AtXBhgCUQt9T6KIvUA=; b=J6dkO4I+PAhAFF3MHAag2hDA0j2mmIc9Xb6sqza9idbuHYq3Ph2xTyqDHj8b/YkSMH lI2ebq0spAM8qV/1o1uhcu3Fln1BCRTQvoRZihq/KP8DXacxDwNGMgXP0Rf64FO+3eq3 8e21IjY5F/8uNdwOCjRivht//dfnH+M2J/BYLFZ/IsSAFFselKX5XiSQG+L8nDWFvl3Q xEKhykArRrKwNXKnN/mlIx8X3PW1cx4m7T1f5O+CEJ+oPSaK92XhSGiKXi6LpO0i6rST MLWjY6hXj6dwxDNeElCuwUuro5OnxXTxm2MjW/kcF5LdmQmEI08169YtsMCRFsAhTJXO 99Sw==
X-Gm-Message-State: ALoCoQk8J8GEGvdGkVPfFL93rwBj0xq9oBYMxMhlHJ2J8/gAcT9t3YsdKRb28ZrYVbOhW1ubG3G3
MIME-Version: 1.0
X-Received: by 10.224.69.67 with SMTP id y3mr6826875qai.59.1422398747815; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
Received: by 10.96.238.73 with HTTP; Tue, 27 Jan 2015 14:45:47 -0800 (PST)
X-Originating-IP: [50.206.82.141]
In-Reply-To: <20150127184904.72D211B12B@ld9781.wdf.sap.corp>
References: <CAOgPGoDvPm4GxbhBYbuhDOc1D5iYf0VvCLs+ZORu8n82sfrQKg@mail.gmail.com> <20150127184904.72D211B12B@ld9781.wdf.sap.corp>
Date: Tue, 27 Jan 2015 14:45:47 -0800
Message-ID: <CAOgPGoC9n8p7of-XXh7CCoC18UF19trJW=0_YspqqxzRRZQe=Q@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary="001a11c2d8f617c5ef050daa0423"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-t-5zP4UixVZrkjM5OGnZxMZSEo>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] consensus on backwards compatibility changes
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: Tue, 27 Jan 2015 22:45:52 -0000
On Tue, Jan 27, 2015 at 10:49 AM, Martin Rex <mrex@sap.com> wrote: > Joseph Salowey wrote: > > Dave Garrett <davemgarrett@gmail.com> wrote: > > > > > On Sunday, January 25, 2015 02:36:14 pm Eric Rescorla wrote: > > > > Based on reading the mailing list, it seems to me that there is rough > > > > consensus on PR#105, but not (yet?) on PR#107. > > > > > > I don't recall any objections to #107, but not much discussion either. > > > > > > To sum it up here, in addition to some editorial changes: > > > > > > 1) Fixes initial ClientHello record layer version to { 3, 1 } (TLS > 1.0) & > > > mandates > > > all other record layer versions to match negotiated version. > > > (Brian's suggestion) > > > > > > > > [Joe] I think this makes sense. I added to comments to the PR. I > propose > > to move the bit about the server accepting versions {3,x} to the same > place > > and change the wording of the existing test to say: > > > > "The client MUST set the version to {3, 1} for the initial ClientHello." > > The primary reason why several implementors goofed the TLS version > negotiation in TLSv1.0 is that lack of clarity in the language. > > If your above statement refers to the client_version member of the > ClientHello handshake message, please say so. > > The record layer version number is entirely independent from > ClientHello.client_version, and for additional safety, it should be > explicitly mentioned what requirements, if any, exist for the record > layer protocol version of a record that carries the initial ClientHello > of a connection. > > [Joe] The text above is from the section describing the record protocol and is referring to the version in the record layer of the protocol. I agree that it would be better to be explicit about this as it has generated confusion in the past. > The original idea behind the TLS protocol version negotiation was that > the TLS handshake hash protects the entire handshake, and dirty hacks > like the downgrade dance that contemporary browsers are doing, would > be entirely unnecessary. > > It would be a pretty stupid idea for the TLSv1.3 protocol specification > to withdraw TLS protocol negotiation protection from TLS clients, that > for whatever reason, see a need to offer pre-TLSv1.0 protocols to servers. > > [Joe] Agree, this is not what is being proposed. > Defining an _implied_ set of features, that a TLS client sending/using a > backwards-compatible ClientHello offering TLSv1.3 in > ClientHello.client_version > (or whatever alternative negotiation scheme the TLS WG chooses to use), > would be *MUCH* more reasonable. > > [Joe] I'm not sure what you mean. > > -Martin >
- [TLS] consensus on backwards compatibility changes Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Kurt Roeckx
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Sean Turner
- Re: [TLS] consensus on backwards compatibility ch… Ira McDonald
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Joseph Salowey
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Martin Rex
- Re: [TLS] consensus on backwards compatibility ch… Florian Weimer
- Re: [TLS] consensus on backwards compatibility ch… Eric Rescorla
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Michael Clark
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Nikos Mavrogiannopoulos
- Re: [TLS] consensus on backwards compatibility ch… Dave Garrett
- Re: [TLS] consensus on backwards compatibility ch… Ilari Liusvaara