IETF Logo Mail Archive

Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 21 October 2016 18:11 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 0AED61297C4 for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 11:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level:
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DA8yoRMIfAFc for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 11:11:39 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0120.outbound.protection.outlook.com [104.47.40.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0081295B9 for <tls@ietf.org>; Fri, 21 Oct 2016 11:11:39 -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=y1JQnQzLpPL1RIGVI02YZIQO2B4yonAeoWmQZFq6KCM=; b=fSLPY1e2aW2NOdvVjIrCM6UmgB7rxhtZEdZC/6tSWoqiBOIaWOrO7hIbimuH2G2GMQBhUNtKeUkb6fujqY/1ctIm72+9y4Z6QpUNEolYvwXPa5GLCK3Hjrb4wHYERTIIc+crzCgMbZeCg9gXvY8YLHcpyYuomYLMDWrQQ5W21Gs=
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) by BY1PR0301MB0838.namprd03.prod.outlook.com (10.160.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.639.5; Fri, 21 Oct 2016 18:11:37 +0000
Received: from BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) by BY1PR0301MB0838.namprd03.prod.outlook.com ([10.160.193.144]) with mapi id 15.01.0639.019; Fri, 21 Oct 2016 18:11:37 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzLpp1if3oZyr0eklNKSlm6JUqCyEPywgAAB5gCAAACNkIAA2skAgABEipA=
Date: Fri, 21 Oct 2016 18:11:36 +0000
Message-ID: <BY1PR0301MB0838F819C3273E8F45CA8EB18CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
References: <BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40@BY1PR0301MB0838.namprd03.prod.outlook.com> <20161021135206.B74981A565@ld9781.wdf.sap.corp>
In-Reply-To: <20161021135206.B74981A565@ld9781.wdf.sap.corp>
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::1d2]
x-ms-office365-filtering-correlation-id: ab02fc22-7611-4e74-4ada-08d3f9ddb2b1
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:8CMdCatfIHhiL6VCk17i6gtVsEVXmx+8nzUlegLMC7rmefrwHbHrvje5eWmlMjlTpYt0F9/Z1kWFruJO4i/SJMxwZwmXa/1cUUaFib/Bx3IDHkG3a6LbvBBE1oYhvQUb3NonHmVwsDNBRJcXgszjOVCpt1jhZORUOikByKMtU65nAoea8Z4knkHLJxBhHhRK0WXdYIEFXH5yb8HMB7egznbwwjv5c/wELIMjYBagKXiySiQyJfuRYm1KG5nJGih1yin58GaeV/eDLdZM4tOAiQNG9TFV5cdLplfBrJQ767CxSKbdhYJdUOL7G4xlZpn5y14Y4rGC/T1Kdtl29Wz6iZGMMmlRRvjD7oe120LBIgI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838;
x-microsoft-antispam-prvs: <BY1PR0301MB083877476582152D28E8B6968CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(55761251573089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838;
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(199003)(189002)(586003)(7736002)(5005710100001)(68736007)(106356001)(8990500004)(305945005)(74316002)(106116001)(5002640100001)(3660700001)(50986999)(122556002)(10400500002)(81166006)(81156014)(1730700003)(4326007)(8666005)(5660300001)(2351001)(10290500002)(76176999)(8936002)(2906002)(101416001)(5640700001)(86362001)(7846002)(6116002)(97736004)(99286002)(8676002)(110136003)(102836003)(2950100002)(92566002)(105586002)(87936001)(76576001)(189998001)(54356999)(86612001)(77096005)(6916009)(2900100001)(33656002)(3280700002)(2501003)(7696004)(19580405001)(10090500001)(11100500001)(19580395003)(9686002)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 18:11:36.8392 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB0838
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/V4HubgGCrX3P_eoPIdY933MVVEQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SNI and Resumption/0-RTT
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: Fri, 21 Oct 2016 18:11:41 -0000

> The server ought to perform a full handshake whenever the full handshake will result in selection & use of a _different_ TLS server certificate than what was used for the original full handshake on a session resumption.
I think this is correct, assuming a server is only able to present one cert in a TLS session (which is currently the case).

However, this does not mean that the SNI at resumption time has to match the SNI at session establishment time, because the same server cert can match multiple SNIs.

Also, there appears to be interest in allowing the client to request server auth post-handshake. If this gets supported, a server may prove multiple identities to a client within the same TLS session. And then perhaps the client should be able to resume the session with an SNI that matches any of the identities the server has proved in this session.

Cheers,

Andrei

-----Original Message-----
From: Martin Rex [mailto:mrex@sap.com] 
Sent: Friday, October 21, 2016 6:52 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Eric Rescorla <ekr@rtfm.com>; tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT

Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this 
> session the server has proved an identity that matches the new SNI.
> In order to enforce this, the server would have to cache (or save in 
> the ticket) a list of identities it presented in each resumable session?

The current wording in rfc6066 may be slightly confusing about what is acutally important and why.

The server ought to perform a full handshake whenever the full handshake will result in selection & use of a _different_ TLS server certificate than what was used for the original full handshake on a session resumption.
This is a direct consequence of the principle of least surprise.

This is also the most backwards-compatible behaviour when upgrading the server from a does-not-support-SNI to a supports-SNI state/implementation.

You do *NOT* want to have session caching interfere with the server certificate that a client gets to see, because that would essentially result in not-quite-deterministic server behaviour.

Sometimes there may be bugs in client-side session caching, and clients proposing the wrong session for resumption, and the server doing a full handshake results in interoperable, deterministic and secure behaviour.


-Martin

v2.23.0 | Report a Bug | By Email