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

Benjamin Kaduk <> Wed, 26 October 2016 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 474351293D8 for <>; Wed, 26 Oct 2016 10:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.142
X-Spam-Status: No, score=-1.142 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, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PqmMhY7EMBF for <>; Wed, 26 Oct 2016 10:41:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 81D681293FE for <>; Wed, 26 Oct 2016 10:41:27 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id 0486B433424; Wed, 26 Oct 2016 17:41:27 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id E0017433408; Wed, 26 Oct 2016 17:41:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1477503686; bh=Q80M9cEaypEMDrCFnOmPTx1jzTOpZVSFUe4escz2VU0=; l=15882; h=To:References:Cc:From:Date:In-Reply-To:From; b=HmDo28UGAbegjWudOp6nPSQjtzvzABjEPFA4TnNrUNKkglMySW3IR6pobN+gpvXL/ oQ8NAL5E0TZwWqWTGe4gmZZY+wnrd1CHM2bEQLw407A3mHSndeaxfm8P2ybdjLlFkV Z0VTmxg+FzAjk2mXtH8iG30KkNPVR48neHFAeT18=
Received: from [] ( []) by (Postfix) with ESMTP id 89E961FC8B; Wed, 26 Oct 2016 17:41:26 +0000 (GMT)
To: Victor Vasiliev <>, Eric Rescorla <>
References: <> <>
From: Benjamin Kaduk <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 26 Oct 2016 12:41:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------B67C4FAB41CB01B6E43DAF69"
Archived-At: <>
Cc: "" <>
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: Wed, 26 Oct 2016 17:41:30 -0000

Picking a message somewhat at random to reply to with some more-general

On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> I believe that an ability to resume across different server_name values
> specified in the subjectAltName of a certificate will have a positive
> performance impact on the websites which due to various reasons have
> to fetch
> resources from different servers.  A particular use case I have in
> mind is when
> a website maintains a pool of servers, say, *
> <>;,
> and supplies a
> specific server directly in a resource URL.  In that case, all the servers
> already share a wildcard certificate with a secret, so they can share
> a ticket
> key too, meaning it makes sense for them to accept the ticket issued
> by another
> server in the pool.

I think it is useful to distinguish between this case, where
[cdn.] is the owner of all the content involved, from other
co-tenanted names that have different content owners, such as from a
shared hosting service.  The wildcard cert is pretty clearly in the
"same content owner" case, but even subjectAltNames in a single cert do
not necessarily provide the same indication -- I understand that some
CDNs offer a lower-cost TLS option by means of being a SAN on a cert
that shares names with many different CDN customers.

So, even the server's configuration settings may change as a result of
SNI (e.g., a hosting provider may let customers configure settings
differently even when served from the same TLS server).

> There are potential confusion issues associated with using a ticket for a
> different server name, both with the server becoming confused and the
> client
> becoming confused.  On the server side, this requires implementations
> to know
> how to handle SNI value change.  I suggest that the servers should
> explicitly
> indicate to the client that a newly issued ticket may be used for all the
> subjectAltName values present in the server's certificate.

I would argue that changing SNI value on resumption or 0RTT only has a
hope of making sense in the "same content owner" case ... but the client
may not have an easy way of knowing, in the absence of an explicit
server signal as you propose.

> Clients must also account for any per-host differences before offering a
> ticket.  For instance, web browsers typically require users to pick a
> certificate for each domain they authenticate to, so resumption across
> different SNI values should obviously not happen here.  One can also
> imagine,
> say, a client which uses different cipher configuration or a different
> set of
> trust anchors for each host.  In all of those cases, it is on the
> client to not
> cross-resume, but a lot of those concerns are application-specific in
> nature,
> so I am not sure how much guidance can the TLS specification provide
> on this
> matter.

Things are getting messy enough that I'm starting to lean towards just
not doing it at all (perhaps with the carve-out for future behavior that
Chrstian wants, if we can satisfy ourselves that it won't ossify).


> On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <
> <>> wrote:
>     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.
>     Comments?
>     -Ekr
>     [0]
>     <>
>     [1]
>     <>
>     [2]
>     <>
>     _______________________________________________
>     TLS mailing list
> <>
>     <>
> _______________________________________________
> TLS mailing list