IETF Logo Mail Archive

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

Kyle Nekritz <knekritz@fb.com> Tue, 25 October 2016 01:09 UTC

Return-Path: <prvs=9106d40f6e=knekritz@fb.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 C2F6C129A08 for <tls@ietfa.amsl.com>; Mon, 24 Oct 2016 18:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=IIaaWWsA; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=KNAvemHH
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 LM-toO6F_N5D for <tls@ietfa.amsl.com>; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 269FA126CD8 for <tls@ietf.org>; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9P14UsE010708; Mon, 24 Oct 2016 18:09:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=dqjmT/l8fNZo1RSAONwk60B4xO6993/NfGKq1so1oEk=; b=IIaaWWsAc8tYK7HxyX3XdMdRPjO8AVWFqgz/En230hqKJkzQjo428CO8GUTomprNUTqr ko/vGseFMXg21W6JK8Rd39ydfHu7G5PphbcrX8WGIMXLt6SeWyhCYeXyMS36vdOPVssK BZkupmcGhYXSGxH5L7HgRWu39N9TsAEZHSE=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 269s4d9w40-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2016 18:09:54 -0700
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.21) with Microsoft SMTP Server (TLS) id 14.3.294.0; Mon, 24 Oct 2016 21:09:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dqjmT/l8fNZo1RSAONwk60B4xO6993/NfGKq1so1oEk=; b=KNAvemHHZygd9cgKeOzuUpRgUe/CYvddcN1P+jXfK9gfGFkVc7bE6JPkBHQ+YZeFoc27zl1kVihY6NVx01Xs6AvvmUoCX9Nfqm/p2zFCkqklCRPsjN7H/vviU3y2s3RGcftZpwElOziPNn21fLebpSMqA+or8uK17c835pWljoM=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Tue, 25 Oct 2016 01:09:45 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0679.012; Tue, 25 Oct 2016 01:09:45 +0000
From: Kyle Nekritz <knekritz@fb.com>
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzL1pALf5VOBjEej9Ya71kljcaC4Wb+w
Date: Tue, 25 Oct 2016 01:09:45 +0000
Message-ID: <MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80@MWHPR15MB1182.namprd15.prod.outlook.com>
References: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
In-Reply-To: <CABcZeBNroww_zA0BRsMrZPMCrF42b2OZPsQNZ9w0bjPoF+fSHw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c091:180::1:b71d]
x-ms-office365-filtering-correlation-id: f9e7bb3d-3855-4d8d-d2f5-08d3fc739c07
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1182; 20:T8OPhM8jRy48uXWxmEFYMdFRCI7qVTIBJpoUIy4Qv+cLSNAJ6ZQxy5J4Jj1aJQXF3TNRyvurKk7+UTY/ys2kYKWHf2o0AgReBUx8v/mcJ3OepqeWcT3A4Y7f7K+jhkEti7b1fcWKcfdOKtZMyjGu31t8vaomEpBfuqgaFB48fCI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1182;
x-microsoft-antispam-prvs: <MWHPR15MB1182047775B80909432C708BAFA80@MWHPR15MB1182.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR15MB1182; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1182;
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(189998001)(97736004)(19580395003)(9686002)(5001770100001)(19617315012)(2501003)(8676002)(2900100001)(19609705001)(15975445007)(7846002)(3280700002)(5002640100001)(122556002)(87936001)(107886002)(5660300001)(54356999)(76576001)(2950100002)(76176999)(77096005)(7696004)(8936002)(50986999)(105586002)(92566002)(86362001)(99286002)(101416001)(19625215002)(68736007)(106356001)(106116001)(7736002)(11100500001)(7906003)(586003)(19300405004)(10400500002)(2906002)(102836003)(6116002)(790700001)(33656002)(81156014)(81166006)(74316002)(3660700001)(16236675004)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1182; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182E0D0F4FE9DFB7D772CF9AFA80MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2016 01:09:45.4915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1182
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-24_19:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GUTRb9GR7Atrrg6qzVXzKdlsaeU>
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: Tue, 25 Oct 2016 01:09:57 -0000

I do think this should be allowed if the client is satisfied with the previous identities presented. We currently allow resumption across domains supported by our wildcard certificate (I believe this is fairly common practice), and our clients take advantage of this to improve their resumption rate. In regards to the referenced paper, I don’t think this is any more dangerous than the wildcard certificate itself as a full handshake would succeed anyway. I don’t think it’s entirely necessary for the server to opt-in to this either, if the server wants it can simply reject the resumption attempt.

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 8:34 PM
To: 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcmarkup-3Fdoc-3D6066-23section-2D3&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=7lJsgC6sHRMouuFOq6wDh4N72rm4yWm2VW6gd2zCvdQ&s=RMozNpWLpaS7k3E6SrgmGx-BrX-olX_B5oGaNDICn_M&e=>
[1] https://github.com/tlswg/tls13-spec/commit/b26093b5e9143fb61f5b619d1da78c4ba54b2121
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__antoine.delignat-2Dlavaud.fr_doc_www15.pdf&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=7lJsgC6sHRMouuFOq6wDh4N72rm4yWm2VW6gd2zCvdQ&s=HBfcl1svWchDshZqQKO_NCVPq2TcxvaGaDaFdMXSG78&e=>

v2.23.0 | Report a Bug | By Email