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

Kyle Nekritz <> Tue, 25 October 2016 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F6C129A08 for <>; Mon, 24 Oct 2016 18:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.731
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: (amavisd-new); dkim=pass (1024-bit key) header.b=IIaaWWsA; dkim=pass (1024-bit key) header.b=KNAvemHH
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LM-toO6F_N5D for <>; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 269FA126CD8 for <>; Mon, 24 Oct 2016 18:09:55 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u9P14UsE010708; Mon, 24 Oct 2016 18:09:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 ([]) by 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 ( by ( with Microsoft SMTP Server (TLS) id; Mon, 24 Oct 2016 21:09:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( by ( 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 ([]) by ([]) with mapi id 15.01.0679.012; Tue, 25 Oct 2016 01:09:45 +0000
From: Kyle Nekritz <>
To: Eric Rescorla <>, "" <>
Thread-Topic: [TLS] SNI and Resumption/0-RTT
Thread-Index: AQHSKzL1pALf5VOBjEej9Ya71kljcaC4Wb+w
Date: Tue, 25 Oct 2016 01:09:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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: <>
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;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( 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-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: <>
Subject: Re: [TLS] SNI and Resumption/0-RTT
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 [] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 8:34 PM
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 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.