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

Roelof Du Toit <Roelof_Dutoit@symantec.com> Tue, 07 March 2017 20:04 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 8B4CC129569 for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 12:04:30 -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 OrM6aHy-MJ4d for <tls@ietfa.amsl.com>; Tue, 7 Mar 2017 12:04:28 -0800 (PST)
Received: from asbsmtoutape01.symantec.com (asbsmtoutape01.symantec.com [155.64.138.35]) (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 A61DD129426 for <tls@ietf.org>; Tue, 7 Mar 2017 12:04:28 -0800 (PST)
Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat6.net.symantec.com [10.90.75.6]) by asbsmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id D0.1F.36325.B421FB85; Tue, 7 Mar 2017 20:04:27 +0000 (GMT)
X-AuditID: 0a5af819-428639a000008de5-8e-58bf124b56d4
Received: from tus3xchcaspin01.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat3.net.symantec.com [10.90.75.3]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id BA.7D.09705.B421FB85; Tue, 7 Mar 2017 20:04:27 +0000 (GMT)
Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) by tus3xchcaspin01.SYMC.SYMANTEC.COM (10.44.91.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 7 Mar 2017 12:04:25 -0800
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.9) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Tue, 7 Mar 2017 12:04:25 -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=M4WHxHVnUYRZ+NbSOoytCUC+r6MPgV0pliEuTrouUIc=; b=3dPDafF+g9dX3m90GCKkyQIazjURPZd5tKiuAD90Rowu6wx23WjAFaookMlxKie4GXj/uS68JEYkloisRwcFaBfQWqav5U6asnbq59KbXvCu7B8LWIFTCXjHVe278kzlujrgOsCKAkEAqIGmt2obZYt7DAAcyz+tyMyUZmFKwio=
Received: from DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) by DM5PR16MB1834.namprd16.prod.outlook.com (10.172.45.9) 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 20:04:23 +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 20:04:23 +0000
From: Roelof Du Toit <Roelof_Dutoit@symantec.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Allow KeyShare in HelloRetry if not advertised in ClientHello?
Thread-Index: AQHSl2p+vyKS4/mfNkq7sGwa67WGLaGJp0sAgAAEroD//8VQAIAAV/aA//+wIAA=
Date: Tue, 7 Mar 2017 20:04:23 +0000
Message-ID: <7C5FFCA0-E33C-4130-8B4E-0102CB40FC5F@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> <D06DC120-231A-4349-9C69-51FAB0B1C77E@symantec.com> <CABcZeBNgjhJ6xgxDCXUYJkE9DaXvEAk6f-u8=LO3wVYgO4uERQ@mail.gmail.com>
In-Reply-To: <CABcZeBNgjhJ6xgxDCXUYJkE9DaXvEAk6f-u8=LO3wVYgO4uERQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; 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; DM5PR16MB1834; 7:ve84MRmAPOGjtDsnIj+usug0uWEYSeXlLncryJJez7D3NWEl7XqLB1+bnmkW+AXxBJLezBjZ9/KAaNnqOLAiJXRgO2lPhRc38/IWqE1sg9rb8zi2ZtZYdHe+bVf6u/Fmj/2AzypsJ6Q2CHee0sKe6TesGBCqftCd8HFMJ+sVEC6bhclkJcnQxlFkCAANJ5Viz0HDzcxknIhdDeoKff2vIkqnPQ/l3JHn0wgMqc8f3ygIssR/8X/JMXenIwlEE3oZwsvHtqc3JGXQUmZQnZiDPIGlp+IzFuaW3dRLVnm3o3u2I/tAo3ASOASLXb9fEzWfofsdERHKcZVYhvnT2gENaA==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39450400003)(377454003)(24454002)(83716003)(4326008)(6246003)(106116001)(38730400002)(110136004)(82746002)(2950100002)(2900100001)(8676002)(236005)(54906002)(6916009)(77096006)(606005)(25786008)(6436002)(86362001)(7906003)(6486002)(53546006)(10290500002)(80792005)(50986999)(6506006)(6512007)(36756003)(33656002)(54896002)(122556002)(5660300001)(6306002)(66066001)(7736002)(3280700002)(76176999)(54356999)(99286003)(93886004)(8936002)(53936002)(102836003)(3846002)(6116002)(229853002)(2906002)(189998001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1834; H:DM5PR16MB1834.namprd16.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: ca9eca03-cb22-4158-665f-08d46595263f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR16MB1834;
x-microsoft-antispam-prvs: <DM5PR16MB18348587F641B9BED06CFED7FA2F0@DM5PR16MB1834.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)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:DM5PR16MB1834; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1834;
x-forefront-prvs: 0239D46DB6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_7C5FFCA0E33C41308B4E0102CB40FC5Fsymanteccom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2017 20:04:23.0272 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1834
X-OriginatorOrg: symantec.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0jTURTHufv9tv1cDW6b5kmJbFiY+IQk/9BKCTIsS8wSQern/JXik00t jWIJCU4Ry8LykXM5UVHUfGKCaYv5yHdqLFLElZQg+cJXRm5Xw38un3O+33PPOZfLUJJPfDsm JiGZUySwcTKBiBaFBwpcAyWdYR7Nzd7e71a9vCvnB4XeS0NqdJ4KKFKN0AHl5Ru8gPzZTOoa FS7yieLiYlI5hfvZ26Lorg0uqXIE3V/cGqBUaLYfqZEVA/g0bFe/FqiRiJHgRQRG3dB/Qbte zCPCGoJhbYnQLEiwHsF0sS0R5hAsNf+2lNM4i4IZVdluyVMeDH1ppEnQheBXl45nrhdgT9h4 /4xvZmvsAJt/emgzU/gStFTMUmaW4hCo2s5DxHMdlpuqBISDYOJzmWUOGjuCxqSx5MX4HBgq ChBp1seDyT5issLB0PL4jaUxwodhra+GR5rZgtFUyiObYijvGKII28DP2b9880UIZyMwNLfu Ci4wMGnafZpjMP2939INcA4Fubp6IQna+ZCrMdLEdQWGM0rRHhtGNnc5FuqNa0LCgdDaN0nn IbfCfVMRlkPbulpQaFnvEPS+MtGFiNnJn4K6dndiOQ7Ps2eEhJ3gSXGJkFgCYCXLb79Fg5hq 5MAqI5XxyYkpyWwS5+HppkyLl5sPdueHyd3kifFvkeWPrR9pQ/qey90IM0h2UPwAd4ZJ+Gzq jrMbAUPJrMXz/J2UOIpNS+cUibcUKXGcshvZM7TMVrzwozZMgu+yyVwsxyVxij2Vx1jZqVCD 78dRRysX9zM100VtC/f0Nqk3NzQTBzKPpkcwoQ66jtARr1xmvm0lJX8sIUSoD5JsScdXg1f8 7lRvRvrlSFeWpwZ7r564UTo145MvfWHvlFTg+/WC1l9tqP0ww49xdn35cCyiqmE88lHLwMXG 8TrdyZYmo3/Gt9E5rW+10JiQJ6OV0aynM6VQsv8A12BnbV8DAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+d17t11H1q9VerCXjoqSUteDRKKHkFhm2AMa+6du6/pAXbJr mkgyiwIfiGVULs1pc2gEijVfZaWE1sTHQnQJJaJiWVFaOd+2u5+B//z4fH/ne37nnB+HpRXV Eh82TpfM63VcglIqZ+SaCHpXhOK1OujGhH/wi7/7giu+dcqCJ7qy0WE6/KHBzoSbzdNUeMHQ LTqK1sgPXOIT4lJ4feDBC/LY5mk+qcKOro7PdtAGNNSOspEHC3gvlE0VUdlIziqwE0F3WbFM DCjwWwQDRd4kMIpgwvpLKgoGZ9EwaChdSrlNQZfjGUNEM4Kx5nJKzJdiFUy/uSMReS32hZm5 d4zIND4GtZYhWuQ1+AxUzucj4jkLv59XSgmfhN6eUncfDN4CpmGT+94TH4I2y31Eitko6LMR kwc+BbWZj92FEfYCp+0pRYp5Q/9wCUUmxWB+2UUTXgdfhxYk4kMI5yBos9YtBXZCR9/w0tds hoGRdnc1wLk05JVXy4holECeqZ8hrkjovl6C/nObfWaJ46G63ykjHAF1tj6GJBspsNY2uQTr EhugYXpPPvI3LuuWsBbqp7KlRvfYq+F94TBjdGXQeAdUNQYSix/czRmUEd4ON4uKZcQSDn+y jiy3mBD7BPlywkUhMTkxmeOS4oJ2BwhpiVrx4FwLpg3QXk6sQe4Vm/WuR51zJ1oQZpFyhadh 4ZVaIeFSXM4WtJ5llN6eDlWNWoFjuGQ+nueTeP15/ZUEXmhBFOvhY0DmxdDcqPh7wlHnA6/F jKrTK3tklo6K1smNprpHP1Yprh1v1XBhEebAD9bCnyqvkA5r2GfPrIz9Bu5T6HhBa1N0WqpO GI2xOGrTR7YaSyO3aTStPr25fnHdlpBNQV+az3nIdd8r7SMf1e0DfNZ8boXQHz2ZOZbqaHBq oy3pukElI8RyKn9aL3D/AIq1G5dDAwAA
X-CFilter-Loop: ASB02
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Mlil4-oLW_M1R7T4qHURDRP8PnQ>
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 20:04:30 -0000

Thank you Eric

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

This appears in https://tlswg.github.io/tls13-spec/#resumption-and-psk

"As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify message. When a client offers resumption via PSK, it SHOULD also supply a “key_share” extension to the server to allow the server to decline resumption and fall back to a full handshake, if needed. "

-Ekr




On Tue, Mar 7, 2017 at 11:35 AM, Roelof Du Toit <Roelof_Dutoit@symantec.com<mailto:Roelof_Dutoit@symantec.com>> wrote:
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<mailto:davidben@chromium.org>>
Date: Tuesday, March 7, 2017 at 1:05 PM
To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>, Roelof Du Toit <Roelof_Dutoit@symantec.com<mailto:Roelof_Dutoit@symantec.com>>
Cc: "tls@ietf.org<mailto:tls@ietf.org>" <tls@ietf.org<mailto: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