Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?

Roelof Du Toit <Roelof_Dutoit@symantec.com> Tue, 07 March 2017 19:35 UTC

Return-Path: <Roelof_Dutoit@symantec.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 93CCA12948F for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 11:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.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 CMO1LazcVD3L for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 11:35:25 -0800 (PST)
Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E56A12943D for <tls@ietf.org>; Tue, 7 Mar 2017 11:35:25 -0800 (PST)
Received: from tussmtmtaapi01.symc.symantec.com (tus3-f5-symc-ext-prd-snat9.net.symantec.com [10.44.130.9]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id AF.12.30096.D7B0FB85; Tue, 7 Mar 2017 19:35:25 +0000 (GMT)
X-AuditID: 0a2c7e31-bbf679a000007590-c7-58bf0b7dd664
Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat9.net.symantec.com [10.44.130.9]) by tussmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id F0.90.61790.C7B0FB85; Tue, 7 Mar 2017 19:35:24 +0000 (GMT)
Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 7 Mar 2017 11:35:24 -0800
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.128.1) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 7 Mar 2017 11:35:23 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VUxWjjjJqjbM6OAZz1q3WbKclrEA8rdYppavk59809M=; b=PyHjW8I8Mb5TQb1WgClIWxbNI42Noa5ic3VEMHVTNkeT2l1QOgsi2omHd1Bf/61pg/dUsfk4CDmUsPSwqc0lVryhBGIVzXTRmG3gAAvAh+ClBFOHoGG6Vo9GQkzj11H9wZHXL4WcjNWEOlh56+O0gfLsBUzTLEz8yzTjEED358c=
Received: from DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) by DM5PR16MB1836.namprd16.prod.outlook.com (10.172.45.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 7 Mar 2017 19:35:22 +0000
Received: from DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) by DM5PR16MB1834.namprd16.prod.outlook.com ([10.172.45.9]) with mapi id 15.01.0947.020; Tue, 7 Mar 2017 19:35:22 +0000
From: Roelof Du Toit <Roelof_Dutoit@symantec.com>
To: David Benjamin <davidben@chromium.org>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?
Thread-Index: AQHSl2p+vyKS4/mfNkq7sGwa67WGLaGJp0sAgAAEroD//8VQAA==
Date: Tue, 7 Mar 2017 19:35:22 +0000
Message-ID: <D06DC120-231A-4349-9C69-51FAB0B1C77E@symantec.com>
References: <B6B302EF-6836-4E50-B916-D9260C16D25B@symantec.com> <CABcZeBPT7W=hY5KZVW=A-3FpzpY_c_Gj4Tfh+YzYBgNqrVcHfw@mail.gmail.com> <CAF8qwaA+yU3=wjonBV6Ru+x+ffCLazjSKnwjvzRqg=RwUnCHXQ@mail.gmail.com>
In-Reply-To: <CAF8qwaA+yU3=wjonBV6Ru+x+ffCLazjSKnwjvzRqg=RwUnCHXQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=none action=none header.from=symantec.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [72.23.5.194]
x-microsoft-exchange-diagnostics: 1; DM5PR16MB1836; 7:/m9MpC5YGACqLszkazIypT8/EyAweQbaw6sb0C0LXNUMed1ffJw/9wQDjGfVVEGaGDviZytydYt89x8ExOXRsjIf/um2MOVniV3VLCfi1N9DI1389RtHVEULG/OquQqiBWze3RI7a4RiImvLBkLuLryOYjtzSz8gNTwRgHkDeBp+lhFy2TDwAagimrzsLIGJ97TA2USr5nvXbYVB2EFAb9K+fL9Hgxq9T1++xXjF8Klxa6z69N4sHhItootWFmOVLlVsc2Zw7qaSwig2z/V/ylDSbPxqQq1mOM9fVaXhwPj8KgCavdaZHDOQv3NPJxPVO+IJfOfwC7smRVRIPgt1KA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39450400003)(24454002)(377454003)(3280700002)(80792005)(2906002)(76176999)(189998001)(106116001)(33656002)(54356999)(83716003)(50986999)(2900100001)(66066001)(38730400002)(102836003)(4326008)(53936002)(2950100002)(7906003)(5660300001)(7736002)(6116002)(122556002)(53546006)(10290500002)(3846002)(6246003)(6512007)(3660700001)(6306002)(6506006)(54896002)(25786008)(8936002)(236005)(99286003)(229853002)(86362001)(6436002)(82746002)(36756003)(606005)(77096006)(8676002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1836; H:DM5PR16MB1834.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: 24dda46d-a1e1-4545-c57e-08d465911890
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR16MB1836;
x-microsoft-antispam-prvs: <DM5PR16MB18364D9A5500FDD76643C8FDFA2F0@DM5PR16MB1836.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:DM5PR16MB1836; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1836;
x-forefront-prvs: 0239D46DB6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D06DC120231A43499C6951FAB0B1C77Esymanteccom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 19:35:22.1324 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1836
X-OriginatorOrg: symantec.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXCpdPEqVvLvT/CYNFKNovdX00tVrw+x27x 6XwXowOzx+yGiyweS5b8ZPKY/LiNOYA5issmJTUnsyy1SN8ugSujae0iloJPyxkrdj1dx97A uHkxYxcjJ4eEgInExcsPmbsYuTiEBD4xSmw+/4cZJrFi5ycmiMR3RonZN69DOYcZJeZ8XATV 8pxR4tCGrYwgDotAJ7PEtw2PocomMUk8OvuVEcI5yCjxr3ENK8hkNgFDiZ8HJoHZIgIeEl82 rGIDsZkFFCXeX5rHAmILCwRLrPw7gRGiJkTi85aVQDUcQLaTxP+zWiBhFgEViXUX7oKN4RWw l9jbfIUFYtdZRoknOz+CzeQUCJR4+H8LO4jNKCAm8f3UGiaIXeISt57MZ4L4VEBiyZ7zUF+L Srx8/I8VZBCjwGRGiXP/V0DDSUfi7PUnULa8xP2np6HsHmaJ1dM5QRokBCaxSpyefAtqkq/E jpYzbDD2xWUHmUA+kBDIlpjaHgkR9pbYfuo6ywRGvVlIboKwkyVOfjzLMgvsOUGJkzOfANkc QHFNifW79GdBg2tK90N2CFtDonXOXCjbQ+Lj4iNsyGoWMHKsYlQoKS0uzi3JLy1JLEg1MNQr rsxNBhGJwBSWrJecn7uJEZzG6gx3MD7a4HOIUYCDUYmHd8mvfRFCrIllQJWHGCU4mJVEeF+z 7o8Q4k1JrKxKLcqPLyrNSS0+xCjNwaIkznv+2doIIYH0xJLU7NTUgtQimCwTB6dUA6ProzdS 9p0X2Kqb/92WY1M3jNwzf56NPfdbvZXK7gqTeM2YZM06nCPLzJ/JGZmW2hk/DNp2S0ZmmdRu j+uGaY9VE7YZTA3envK5b33B5q37Dt+csn2Z0tkVL7taz52cMs1YovRkwTlL0xIvw4oZShz8 3S//JJXLq8qKm807/CT46uIYnyPWOkosxRmJhlrMRcWJAIqSS/pfAwAA
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d17t92tBr+W6cECUwxKlu9CLEp60KCiJzIjyLUuKTqTbYpC mJkZPghxRjltiYo6s7V8oPNVLs3UphmZtRhiKiFCMR+JUdru7gL/+fE5h+/5nt85HJqUmHm+ dGKKllGnKJID+CJKJM0R7r256aU89PNSdFTn8r6o+vkRQdTCaAGKIWXl2WOUrKZmlZDppvPI s+Ql0cFrTHJiOqMOORQvSsh5VkWlLtShjI5ZkyAbNVejAiSkAUdCvWWBKEAiWoJXEJR/mfAE rxFUOKtILviOwGpuRWxA4XwSfpmnPbISAr7ZlhEX9CJYu93IY535OAxWX5W42QvLYMncwGeZ xP7w84OBYnkrvgDGv8WI01yExRajS0O7+Ais24LYNIUDwfTe4bYR48PQfecjxfWyIZixON2e QnwOptZbBCwj7A0rQ40E18sH7DNPCG5SDDVdoyTH22Bueo3HGiGsQzCyXu9ZhxRsEzMe9oPJ 2WEPF5Hw9KGQLQBcwoNhnd3jdBrac9/x//NYbS/BTgA4CR7ci+PSJ6FtaILiavUEmFaaEafZ AZbViGIUpN/wV46VMOi0UXr30FtgsGzGxbQrvweed4ToPWssLZwScLwb7lY89rAMnNV9/I2a SkQ3oJ3aNI1GpVVpFYrUxNCwYE2mSsk+CteBKYOVN1RNyH1iR6Ed9fw5ZUWYRgGbxTJbj1zC U6S7lFa0naYCfMSLYU1yCb6u0DJJDJPKqK+o05IZjRURtNA3GxlyDaNe+40xTHhdtF+b5YS0 Nvb8sDXuWOUif7Jz7mpm/Lx9fImg5a3Kcatcn0XMCc7ElEWV0n2BvNwusTxH0m34PdtdXhY3 eMC7N6/qxdfetoq3xx/lR9gH+n9IdQO2jE+xbywGR+At0/1dtUZHeEjyZeSfZi/sn4os2uLI CqA0CYqwIFKtUfwDydIk4kMDAAA=
X-CFilter-Loop: TUS04
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cE-43LP545bjOyRInlmuUij21eo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?
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: Tue, 07 Mar 2017 19:35:27 -0000

Thank you.

The following text in 4.2.7 prompted my scenario:
""
A server which receives an “early_data” extension MUST behave in one of three ways:"
..
- Request that the client send another ClientHello by responding with a HelloRetryRequest. A client MUST NOT include the “early_data” extension in its followup ClientHello.
""

My conclusion from your replies is that the burden is on the client to avoid the scenario by including an empty key_share (with corresponding sigalgs and supported_groups) when sending early_data with psk_ke mode (vs psk_dhe_ke).  It might be worth warning implementers about that in the spec.

--Roelof

From: David Benjamin <davidben@chromium.org>
Date: Tuesday, March 7, 2017 at 1:05 PM
To: Eric Rescorla <ekr@rtfm.com>om>, Roelof Du Toit <Roelof_Dutoit@symantec.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?

On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit <Roelof_Dutoit@symantec.com<mailto:Roelof_Dutoit@symantec.com>> wrote:
All,

The current language in https://tlswg.github.io/tls13-spec/#rfc.section.4.1.4 states:
As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the “cookie” (see Section 4.2.2<https://tlswg.github.io/tls13-spec/#cookie>) extension.

I am analyzing the following message flow:
ClientHello
+ early_data
+ psk_key_exchange_modes = psk_ke
+ pre_shared_key --------->
(Early Data) ---------> *reject*
<--------- HelloRetryRequest (not allowed to add key_share)
ClientHello
+ supported_groups
+ key_share ---------> *not supported*

At that point in the flow the server is not allowed to send another HelloRetryRequest.  To avoid that the client would need some hints in the HelloRetryRequest.
Would it be possible to allow an exception to send key_share and/or supported_groups in a HelloRetryRequest if not offered in ClientHello?

I would prefer not. If the client is willing to do DH, it should offer KeyShare in its initial ClientHello.

 In particular, per 4.2.5:

"Clients MAY send an empty client_shares vector in order to request group selection from the server at the cost of an additional round trip."

David