[TLS] Keyshare extension spec

Christian Huitema <huitema@microsoft.com> Sat, 12 December 2015 01:13 UTC

Return-Path: <huitema@microsoft.com>
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 C7A5A1AC3F4 for <tls@ietfa.amsl.com>; Fri, 11 Dec 2015 17:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, 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 NIt8iGj5aG5l for <tls@ietfa.amsl.com>; Fri, 11 Dec 2015 17:13:21 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6921AC3EF for <tls@ietf.org>; Fri, 11 Dec 2015 17:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L4nkca5VR7I6JFF1sJ5wteHH4ZA8dz2O3W4euwjScNI=; b=b/hX9LTzcZcIiH6Yxz7fsZjSdq3fN/8daaAcybPNYRMnY0+0XGBrsgIBVSdeqm4osBMl9IhZbQ8Tfv049tuMTUAVa2o5pAgL6eq/H7W+fVFlZAfmZE7IpWW8M/TfQiVXzR032u5tgICy7vYeEXGS02YCkejw6pnww3kSGctPYtA=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.337.19; Sat, 12 Dec 2015 01:13:05 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0337.024; Sat, 12 Dec 2015 01:13:05 +0000
From: Christian Huitema <huitema@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Keyshare extension spec
Thread-Index: AdE0eKM1EhZKH59eROCP64yUPttwyw==
Date: Sat, 12 Dec 2015 01:13:05 +0000
Message-ID: <DM2PR0301MB065556F2C5E0449C207C0BD0A8EB0@DM2PR0301MB0655.namprd03.prod.outlook.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=huitema@microsoft.com;
x-originating-ip: [2001:4898:80e8:d::aa]
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 5:xtT9VIDY01hbheC52A3ePFML6fSLwEviiEo07PTLP0BBHnqZteULPBdQnYmSrgy+sEYVW+vE5hsDwzksKVBjpUgtRnpyDjYelTlJOXGQXfzdNagppwzLeyZGqdNE/upX2PlO1/BR9XA4ZEHKBXKVCw==; 24:2vmmGEpnQdeJpfOeg8JWXlois/hAgq1NQYKVqY7ROWqD6JLAOHzjqJAPJDjeB6SlfWmx09hniOSEnlorCTranaYC6SPqwm6mWBHYyNact2o=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653;
x-microsoft-antispam-prvs: <DM2PR0301MB0653A34B23300634FB91820BA8EB0@DM2PR0301MB0653.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653;
x-forefront-prvs: 07880C4932
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(199003)(5001960100002)(10290500002)(105586002)(10400500002)(74316001)(106356001)(5005710100001)(54356999)(8990500004)(2900100001)(229853001)(2351001)(10090500001)(99286002)(76576001)(450100001)(50986999)(97736004)(110136002)(5003600100002)(107886002)(1220700001)(1096002)(101416001)(5004730100002)(92566002)(5008740100001)(5002640100001)(33656002)(86612001)(86362001)(77096005)(189998001)(2501003)(81156007)(40100003)(102836003)(11100500001)(6116002)(122556002)(1730700002)(586003)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2015 01:13:05.1062 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YjijgYdQ7WmQ9E3K-hkr0OgtRMI>
Subject: [TLS] Keyshare extension spec
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: <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: Sat, 12 Dec 2015 01:13:25 -0000

I am looking at the specification of the key share extension, section 6.3.2.3 of the 1.3 draft. I think that the behavior is somewhat underspecified. The spec says: 

...Clients MAY omit this extension from the ClientHello, and in response to this, servers MUST send a HelloRetryRequest requesting use of one of the groups the client offered support for in its "supported_groups" extension. If no common supported group is available, the server MUST produce a fatal "handshake_failure" alert.

I am concerned with the hypothetical case in which the client sends a list of groups in the "named group" extension but only sends keys for a subset of these groups in the "key share" extension. For example, a client might propose secp256r1 and secp384r1 in the named group extension, leading the server to select secp256r1, but only provide a key for secp384r1 in the key share extension. The server has two options:

* produce a fatal handshake failure alert, because no common supported group is available,
* or, send a HelloRetryRequest requesting use of one of the groups the client offered support for, secp256r1 in the example.

Which is the correct interpretation? Is one of these behaviors preferred, or are both available?

Also, what is supposed to happen if the client sends an empty Key Share extension? Or, if its listed key share extensions list keys for groups that are not indicated in the "named group" extension?

-- Christian Huitema