Re: [TLS] Version negotiation, take two

Benjamin Kaduk <bkaduk@akamai.com> Thu, 15 September 2016 17:14 UTC

Return-Path: <bkaduk@akamai.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 DE2CC12B154 for <tls@ietfa.amsl.com>; Thu, 15 Sep 2016 10:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 1V6seldtRmY0 for <tls@ietfa.amsl.com>; Thu, 15 Sep 2016 10:14:00 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C26C12B7D8 for <tls@ietf.org>; Thu, 15 Sep 2016 09:51:32 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D908D433429; Thu, 15 Sep 2016 16:51:31 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BE079433404; Thu, 15 Sep 2016 16:51:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1473958291; bh=ynYIhNbidiN90wHIg63tKaxMAgdQB8gtaq+07HhP+VU=; l=2407; h=To:References:Cc:From:Date:In-Reply-To:From; b=wxtPIT5yVqojo/uvvtxFBUY88cC2G5Iym0dyfKIcFo66kCA7NR5pxDSmho7r4+jym CxTX+1IfOS8/G4XA7RaZruuXBdz0ivrjpDKyz8cMw9VdjJt6hWw4KlnxaiLA1kIg6m gfsZFaRC+SS2xo83B0QMHfUG28VssznVj8zVu4Tc=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 90EDB1FC86; Thu, 15 Sep 2016 16:51:31 +0000 (GMT)
To: Andrei Popov <Andrei.Popov@microsoft.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com> <4707488.xUP5jY4WDA@pintsize.usersys.redhat.com> <CY1PR0301MB0842F99D7A32DFDCD18B3EAB8CF10@CY1PR0301MB0842.namprd03.prod.outlook.com> <2260393.jBGLD1rnRy@pintsize.usersys.redhat.com> <CY1PR0301MB08422C3C4B9B4029C0B423B58CF10@CY1PR0301MB0842.namprd03.prod.outlook.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5f09fa69-8d0a-8f83-5dda-ce1fabb51250@akamai.com>
Date: Thu, 15 Sep 2016 11:51:31 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CY1PR0301MB08422C3C4B9B4029C0B423B58CF10@CY1PR0301MB0842.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------221CE10A44E4B66D3EEA6FC8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Pt1owAoD3hxe1Fy0qxWLjTUKZI4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Version negotiation, take two
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, 15 Sep 2016 17:14:03 -0000

On 09/14/2016 02:02 PM, Andrei Popov wrote:
> Basically, I don't feel strongly about the switch to the proposed version negotiation mechanism. But if we are going to make this change based on the theory of having only one extension point and actively defending it, then we should probably follow the theory and send a separate TLS extension per TLS version.
>

To me, the (ordered) list of client supported versions in a single
extension feels more intuitively natural, so I want to try harder to
understand the reasoning that leads you to prefer a separate extension
for each version.  Is it just that doing an additional "negotiation"
within the extension body constitutes another extension point that we
would have to actively defend, or is there something else about what a
TLS extension is philosophically supposed to indicate?

Thanks,

Ben