Re: [TLS] draft-ietf-tls-tls13-16

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 28 September 2016 18:31 UTC

Return-Path: <Andrei.Popov@microsoft.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 5A8CF12B2E6 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 11:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 juDolWGTrkI4 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2016 11:31:20 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0097.outbound.protection.outlook.com [104.47.36.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54D712B450 for <tls@ietf.org>; Wed, 28 Sep 2016 11:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VxiP7bLzK4V7hZ9m4QBiiycAgbYS0tFFCueUMe8XuV4=; b=TDQkKiYJr9bi5kLpgEC3zvUb5zYKUaez1WxV2ghB2gTVW4l4BIG/ZkmbnlkkIDPYgLtiCKsacqh8jCVsiEj+ddjnUWHGL7o+eJQ5cvGb8pAylpTBFWWsAgKqpxAec+NNiHFcVQBy20aW6SqClabB7blHh3YRXYIksPjqWq35hhA=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Wed, 28 Sep 2016 18:31:17 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0649.016; Wed, 28 Sep 2016 18:31:17 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, Stephen Checkoway <s@pahtak.org>
Thread-Topic: [TLS] draft-ietf-tls-tls13-16
Thread-Index: AQHSFSsa314HebVjvEW1VTNcRQQ5YqCPGSEAgAABv4CAAALCgIAAD7GAgAATYdA=
Date: Wed, 28 Sep 2016 18:31:17 +0000
Message-ID: <CY1PR0301MB0842527B51B2AF7D6CEA66078CCF0@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CABcZeBOJBNt90XmWAcnpUSnXF1mLx4gdqWnvBRws-o5iO3njXA@mail.gmail.com> <660F59E7-5B9C-4E4D-B12F-EE03BAB333E4@pahtak.org> <7b4c8371a44e4c07be9883d2db959a64@usma1ex-dag1mb1.msg.corp.akamai.com> <153F73EF-492D-4DCC-9D76-62B0FE219F90@pahtak.org> <CABcZeBOuuVx4gH64hWX=UDeOo-mvreLa5zFccGMGQFkzG9FPdg@mail.gmail.com>
In-Reply-To: <CABcZeBOuuVx4gH64hWX=UDeOo-mvreLa5zFccGMGQFkzG9FPdg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:9::1d2]
x-ms-office365-filtering-correlation-id: a683f4bb-70e4-424a-ca3a-08d3e7cda2bb
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:2iicfn8VqHIo2VozC86b6v+7k7iSu/llAT1aZKqaIOb0pY/06hSczB8nXJYMlBC4gBzHU06btYcpkdesQl18EylWrU6YJg6lPuuVnxX6BzfHr4X+gK100Wv6yg2XaKcyjE7CR2N64tx3c1wWdShvBJYyCzuECnwd8M3F+CYXljth6L04oCWrrPaj2e9fsDXJfvukzMf0qmM+5D/+fJwm5K0DnXfBkkpIZZwh2vtdvjMt8cGvotpp9YK2XM+gul32rYnhBgsjeLyXsqcwI/oSZFKtPDq5Z7OGwB4+nq8dB9TNHOB8bZkpkOEztKAzLNHteiSoUVBWCS4BzoOn4QK1PA==; 5:Y1IAyE8OccY8E/cJn6dq88GyAC3ycx3FDXq+N/W/+nk3tzqUnZzBmmBYdPH6gkDhBRtansVdMOZbNlXIfcoS/6LHQ4i2wH4LzK1tpcqSI8cY5LJYrOs7O/042EI5IFsnCLWrWeMDQPQ/H2Tj48qcNA==; 24:Lv2UEzHAGMh+RQ7PqNHnjTlk3ubrXKk7mKyXfr0AqljajBnm8JS1obDIAayJGEEPzN59zJWyY4LBwWWrvB0mzPQrLZnIUXhn2qHJbc6+u0M=; 7:f0zYkCpK9q/XJF7INVdtVRddTHJMOi2vYxa7LpwWz2NgaBG+soJIZpqq4okj55wSNcYC0xkao44GmPvE77JHDISsCv7cKQP5lcG4dHp2tvb9ZCvqhwzAHKldwl8scELZguytzT9XkL199OQXmW34s1rR6314hfIilpq77DqgswJQNTTN+0LNF0expQy0phC3fEHpLrjJ1BWMZMIkyLIwrUtYgpiLVkLGrvRneMjc0LOWIYBzkAX00EJ8R37XAAlrTlcgWzJ9pDGX9/eiw88Oh4hfCQNbmqQ5UbnLBL3ckJzaocQRitk7fSCzqAGu17wr
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844;
x-microsoft-antispam-prvs: <CY1PR0301MB08441BC8BCA29239E04F179A8CCF0@CY1PR0301MB0844.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 0079056367
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(24454002)(189002)(3280700002)(230783001)(2950100002)(3660700001)(105586002)(11100500001)(106116001)(106356001)(5660300001)(5001770100001)(10090500001)(97736004)(122556002)(86612001)(5002640100001)(189998001)(7696004)(19580405001)(19300405004)(10290500002)(87936001)(10400500002)(8936002)(68736007)(8990500004)(19580395003)(5005710100001)(2906002)(9686002)(4326007)(93886004)(86362001)(16236675004)(790700001)(8676002)(15975445007)(81166006)(6116002)(2900100001)(586003)(101416001)(81156014)(102836003)(33656002)(77096005)(19625215002)(76176999)(99286002)(50986999)(7736002)(76576001)(7906003)(7846002)(92566002)(74316002)(54356999)(19617315012)(781001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842527B51B2AF7D6CEA66078CCF0CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2016 18:31:17.1988 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4Fu4VEEdHCmzntZ-pPHymCKDkv0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13-16
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: Wed, 28 Sep 2016 18:31:23 -0000

Ø  I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS.
+ 1
While I agree that the server should be using the server’s preferences in most cases, I see no reason for the client to not list protocol versions (and cipher suites, for that matter) in the client’s order of preference. The client needs to send all supported options; no need to randomize the order.


Ø  Rather, I think we should relax the requirement to pick the highest one, which is just a holdover from a less expressive negotiation mechanism.
In addition, it’s not always clear what the “highest” TLS version is, e.g. in the presence of national TLS “standards”. E.g. a particular server may prefer TLS 0x0100 over TLS 0x0304.

Cheers,

Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Wednesday, September 28, 2016 10:15 AM
To: Stephen Checkoway <s@pahtak.org>
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-tls13-16

I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS.

Rather, I think we should relax the requirement to pick the highest one, which is just a holdover from a less expressive negotiation mechanism.


-Ekr


On Wed, Sep 28, 2016 at 9:18 AM, Stephen Checkoway <s@pahtak.org<mailto:s@pahtak.org>> wrote:

> On Sep 28, 2016, at 11:08 AM, Salz, Rich <rsalz@akamai.com<mailto:rsalz@akamai.com>> wrote:
>
>
>> C.2 Negotiating with an older client says, "If the
>>   "supported_versions" extension is present, the server MUST negotiate
>>   the highest server-supported version found in that extension."
>
> I agree that an appendix is the wrong place to put this.  And that specifying the client order is pointless.
>
> But I disagree with this being a MUST.  There may be times when the server knows more than the client and will know that a lower version is more appropriate.  E.g., interfering middleboxes or regulatory regimes.

Seems reasonable. How about making selection from the list (if the extension is present) a MUST and selecting the highest server-supported version is RECOMMENDED? Perhaps the second part is unnecessary.

--
Stephen Checkoway



_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls