IETF Logo Mail Archive

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

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 21 October 2016 01:00 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 C6236129418 for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:00:25 -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 AUE98tBjmdGc for <tls@ietfa.amsl.com>; Thu, 20 Oct 2016 18:00:23 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0091.outbound.protection.outlook.com [104.47.32.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F311293F2 for <tls@ietf.org>; Thu, 20 Oct 2016 18:00:23 -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=WYSDthed3PaD1KFO8nk6qbjZFgrGrni8LQlo3FsY9Lg=; b=MrNasPjpo3FmkzI7mKrEI0gHQQCUhKKMYzfVDcd5osNolOeQ/rhxOHxJBUXxKZ47MdqRpbzQGsES5fBwLhYUBaZIzqncNm50gwv9ib6M5cHFuSR4QyqTjWBHYon/slNM9jhI5yaGCp0ni7qpNs4/1BvChUYWxeHk0uTesR+UHa8=
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 01:00:18 +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 01:00:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzLpp1if3oZyr0eklNKSlm6JUqCyEPywgAAB5gCAAACNkA==
Date: Fri, 21 Oct 2016 01:00:18 +0000
Message-ID: <BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com> <BY1PR0301MB08382DA7C63232F9DD074D548CD40@BY1PR0301MB0838.namprd03.prod.outlook.com> <CABcZeBO2j+E6MOBQJgpRAcMsLj_72cU-W1q783D9ubZLEPBt=A@mail.gmail.com>
In-Reply-To: <CABcZeBO2j+E6MOBQJgpRAcMsLj_72cU-W1q783D9ubZLEPBt=A@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::1d2]
x-ms-office365-filtering-correlation-id: ede7d1c6-3ba2-4b2f-ffff-08d3f94da055
x-microsoft-exchange-diagnostics: 1; BY1PR0301MB0838; 7:70wrPdg3+cdCEFlOQ2KLwyIskJFBowtBt9K3Yc9mobWH/LQOPmj1AUAzmxYo7+66uHVDNapL6xchrWWM1KQ7XF5r3ZJlQNbAFyWRciJ3hcsyUhSueFcpv59huESXc1lGX64j4neFGfa5E30haQcxI3Cf18O0YQTydyvdBHs0TpD39E2595AYzwb8dyhkJP5IXIqPK+BATrKp9yak4K0yS4TvfIy6lciIFLmSoaZb3V3qJn+nSzhaHOvVuiLc6xsWIGg654qNmO/Iw8SG5ym1FBYqNEZSR6YnFWdfw+3KrXccjw7CnQ2e4NcxKz8gP0IxiJEVaYxjeLiKF3fEJPwwE17Jup9OAqpUGy2TF7B63/4=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB0838;
x-microsoft-antispam-prvs: <BY1PR0301MB083813343D9814ACCA34E98F8CD40@BY1PR0301MB0838.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0301MB0838; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB0838;
x-forefront-prvs: 01026E1310
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(377454003)(199003)(86612001)(54356999)(19300405004)(77096005)(6916009)(105586002)(87936001)(8676002)(2950100002)(92566002)(102836003)(110136003)(189998001)(76576001)(10090500001)(11100500001)(19580395003)(19580405001)(9686002)(7696004)(2900100001)(19617315012)(19609705001)(3280700002)(15975445007)(33656002)(106116001)(7906003)(122556002)(50986999)(106356001)(81156014)(4326007)(10400500002)(81166006)(5005710100001)(68736007)(7736002)(586003)(8990500004)(3660700001)(74316002)(76176999)(5002640100001)(790700001)(86362001)(19625215002)(7846002)(6116002)(101416001)(8936002)(2906002)(5660300001)(10290500002)(16236675004)(99286002)(97736004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB0838; H:BY1PR0301MB0838.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:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY1PR0301MB0838DB70AF5B4667F9B1C3E98CD40BY1PR0301MB0838_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2016 01:00:18.4191 (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/LrSvQIu19EP71TMT1BO3EWESAjE>
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 01:00:26 -0000

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…

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Thursday, October 20, 2016 5:47 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: tls@ietf.org
Subject: Re: [TLS] SNI and Resumption/0-RTT



On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>> wrote:

>  With that said, it does seem like there might be situations where it

>  would be useful to allow resumption/0-RTT with different SNIs.
What are some example situations where resumption with a different SNI is useful

A system where you have a bunch of co-tenanted names and you'd like to get 0-RTT on
SNI A after negotiating with SNI B. Basically the same conceptual situation as Mike Bishops
add-a-server-cert draft.

With that said, I'm more than happy to stuff this in the "TODO-for-later" list.

-Ekr


Thanks,

Andrei

From: TLS [mailto:tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 5:34 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] SNI and Resumption/0-RTT

We used to explicitly say that you had to check SNI for 0-RTT (but
didn't say anything about resumption). On the principle that 0-RTT and
resumption should be the same I removed that, but it turns out that
the document doesn't actually have any rule at all other than the one
we've inherited from RFC 6066, which clearly says that you can't
resume with a different SNI [0].

Following the discussion in
https://github.com/tlswg/tls13-spec/issues/720 I've added a statement
to the draft clarifying that the RFC 6066 rule still applies [1]

With that said, it does seem like there might be situations where it
would be useful to allow resumption/0-RTT with different SNIs. My
intuition (partly informed by [2]) is that this is something we should
be pretty careful about and have the server opt-in explicitly (if at
all) but I'm willing to be wrong about that.

Comments?
-Ekr


[0] https://tools.ietf.org/rfcmarkup?doc=6066#section-3
[1] https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf

v2.23.0 | Report a Bug | By Email