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
>