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

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2016 17:33:41 -0700

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

---

From: Andrei Popov <[email-masked]>
Date: Fri, 21 Oct 2016 00:43:50 +0000

Ø  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?

Thanks,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 5:34 PM
To: [email-masked]
Subject: [TLS] SNI and Resumption/0-RTT

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2016 17:47:04 -0700

On Thu, Oct 20, 2016 at 5:43 PM, Andrei Popov <[email-masked]>
wrote:

> 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:[email-masked]] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 20, 2016 5:34 PM
> *To:* [email-masked]
> *Subject:* [TLS] SNI and Resumption/0-RTT
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 21 Oct 2016 01:00:18 +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:[email-masked]]
Sent: Thursday, October 20, 2016 5:47 PM
To: Andrei Popov <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] SNI and Resumption/0-RTT

>  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:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 5:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [TLS] SNI and Resumption/0-RTT

Comments?
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Oct 2016 18:06:45 -0700

Yeah, it does seem a bit complicated.... :)

-Ekr

On Thu, Oct 20, 2016 at 6:00 PM, Andrei Popov <[email-masked]>
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…
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Thursday, October 20, 2016 5:47 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] SNI and Resumption/0-RTT
>
>
>
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Oct 2016 12:38:29 +1100

So I think that the problem could be reduced in complexity.  A little
at least.  The obvious consequence of changing SNI is that you end up
somewhere different than last time.  But we can still ensure that the
connection is to the same peer.

If the server remembered which certificate it used, and insisted that
THAT remain constant, then you could take a different SNI from - for
example - a subjectAltName.  Provided that the routing works out, you
might still get the same certificate.

I mean, the point of SNI is to route to the right configuration.
Changing name messes with resumption in that you want to make sure
that you end up in a place that has the resumption secret.  But if you
end up at the wrong server, you either fail to resume, or fail to
connect on the normal terms of the protocol.

The only thing that could screw this all up is if we end up in a
situation where one or other peer is confused about either its own
identity, the identity of its peer, or the identity (-ies) that it
believes it peer has for itself.  However, with certificate stability
rather than name stability I don't think we are worse off than with -
say - a wildcard cert.

I agree that the add-a-name stuff makes this harder.  A co-tenanted
server with resumption keys across a bunch of names risks confusing
itself if it allows resumption across certificates, depending on how
much state it carries from the old session.  In doing add-a-name, then
we need to be careful about that, but that's a problem for those of us
who want to do add-a-name.

On 21 October 2016 at 12:06, Eric Rescorla <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 11:55:02 +0300

> resume with a different SNI [0].

If you define "resumption" as "using PSK provisioned by NST", there is
a pretty major difference between "resumption" and "0-RTT".

The symmetry arguments are between "PSKs provisioned by NST" and
"PSKs provisioned externally", not between PSKs of any kind and 0-RTT.

> all) but I'm willing to be wrong about that.

IIRC, Martin Rex used to argue that the rule should be "would result in
the same certificate". Of course, defining the "same certificate" is
way trickier than it initially seems (runs into the same type of
philosophical problems as "Trigger's broom")...

Maybe one interpretation would be that the server can choose a
certificate that is valid for both old and new SNI... That is at least
a consistent rule (no idea about any sort of usefulness).

Or another: The certificate that would be chosen for new SNI is
also valid for old SNI (or vice versa). These rules are subtly
different.

Or saving the list of domains for the selected certificate in
the original connection and then allowing PSK with any of those.

One thing to be very careful of: What careless server that omits the
checks can cause (the checks are relatively complex and subtle, so
getting that wrong is to be expected).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Oct 2016 23:41:59 +1100

On 21 October 2016 at 19:55, Ilari Liusvaara <[email-masked]> wrote:
> Of course, defining the "same certificate" is
> way trickier than it initially seems

Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Oct 2016 15:52:06 +0200 (CEST)

Andrei Popov wrote:
>
> Perhaps it's OK to resume a session with a different SNI if in this
> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 17:03:11 +0300

> Not if you think simplistically: same octets in EE ASN1Cert in both handshakes.

Such behaviour would run into problems with certificate renewal.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Fri, 21 Oct 2016 16:35:12 +0200 (CEST)

> Such behaviour would run into problems with certificate renewal.

Just the opposite.  You definitely want full handshake on
certificate renewal.

I don't know how common it is in TLS servers (and TLS clients) to
allow replacing of TLS certificates in "full flight".  I implemented
this in ours about 10 years ago, and I'm flushing the session cache
after loading of the new/updated cert, so that every new handshake
will result in a full handshake rather than session resume (ongoing
connections continue to use the old/previous certificate until
closed by the application).

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 17:42:38 +0300

> connection is to the same peer.

You _might_ end up somewhere different. And even with the same SNI, you
can still end up to different server in the same "group". And different
SNI names can still get you to the same actual place.

> connect on the normal terms of the protocol.

There are three tasks of SNI:

- Routing to the correct server. Sometimes this routing is performed by
  middleboxes (yay, middleboxes!).
- The certificate selection within the server.
- Set application instance, if the protocol can't do this in-band (but
  if it does, applications generally override this with in-band value).

And I would expect the servers to actually look at the PSKs offered and
not blindly trying to use one, so if connection is routed wrong, I would
expect fallback to the usual DH-CERT handshake.

> rather than name stability I don't think we are worse off than with -

I would expect such confusion about own identity to be pretty much the
norm for HTTP servers. And those are frequently used in ways that tend
to amplify even a small errors to serious attacks.

For other types of servers, I would expect any confusion resulting in
security problems to be pretty rare.

But since HTTP is very important usecase, this impiles that the client
shouldn't attempt to use PSKs when such confusion could create security
issues.

> who want to do add-a-name.

You can already get such confusion with wildcard certificates, no
changes needed.. 

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 17:56:32 +0300

On Fri, Oct 21, 2016 at 04:35:12PM +0200, Martin Rex wrote:
> allow replacing of TLS certificates in "full flight". 

Oh, the library I have written definitely does allowing replacing the
server certificate in the flight. All the way to one thread replacing
the certificate while another is handshaking with the old one in the
meantime. And these replaces can happen behind application's and even
the TLS library's back. So no cache flushing.

-Ilari

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Oct 2016 07:58:57 -0700

I am a bit worried about privacy implications of the SNI. Suppose that we invent an obfuscation mechanism that prevents third parties to track which service corresponds to an SNI string. The SNI would then be different for any connection, including resumptions. Do we want to prevent that with a hard rule in the spec?

-- Christian Huitema 

> On Oct 21, 2016, at 7:42 AM, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Oct 2016 18:14:42 +0300

On Fri, Oct 21, 2016 at 07:58:57AM -0700, Christian Huitema wrote:
> I am a bit worried about privacy implications of the SNI. Suppose
> that we invent an obfuscation mechanism that prevents third parties
> to track which service corresponds to an SNI string. The SNI would
> then be different for any connection, including resumptions. Do we
> want to prevent that with a hard rule in the spec?

Such mechanism on TLS level would be pretty hard to do. You can't do
any sort of static encryption or obfustication for instance (because
that would be trivially attackable).

Much more feasible to have application layer (with possibly TLS protocol
support) way of sending new server certificates in the fly (post-
handshake auth, but with servers).

(It seems to me that due to the roles of HTTP clients and servers, post-
handshake server auth is a lot less scary than post-handshake client
auth).

-Ilari

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Oct 2016 08:42:59 -0700

I mentioned obfuscation as one possible solution. I know that I can make it work for small scale servers, e.g., up to a few hundreds registered clients. But if we can achieve the same privacy results with some mechanisms using dynamic certificates, that's fine too. My only point is, please don't forbid future privacy enhancement with a hard rule on SNI. Maybe something like "should use the same SNI, but may use different ones if client and server agree on an SNI privacy scheme."

-- Christian Huitema 

> On Oct 21, 2016, at 8:14 AM, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 21 Oct 2016 18:11:36 +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:[email-masked]] 
Sent: Friday, October 21, 2016 6:52 AM
To: Andrei Popov <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; [email-masked]
Subject: Re: [TLS] SNI and Resumption/0-RTT

> 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

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 24 Oct 2016 18:48:37 -0400

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, *.cdn.example.com, 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.

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.

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.

---

From: Kyle Nekritz <[email-masked]>
Date: Tue, 25 Oct 2016 01:09:45 +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:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, October 20, 2016 8:34 PM
To: [email-masked]
Subject: [TLS] SNI and Resumption/0-RTT

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=>

---

From: [email-masked] (Martin Rex)
Date: Tue, 25 Oct 2016 12:07:42 +0200 (CEST)

Kyle Nekritz wrote:
>
> 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.

I think it is a bad idea to look at this purely from the perspective
of whether this represents an obvious attack vector.

And there are two entirely *independent* decisions involved.

  (1) whether the TLS client proposes resumption for a session
      (i.e. client-side cache management)

  (2) whether the TLS server agrees to a proposed resumption
      or whether it performs a full handshake instead

And there are _different_ security trade-offs in these two distinct
decisions.

As I previously described my position, I'm perfectly OK with a server
performing a resumption if the full handshake would cause the server
to send/present the very same TLS server certificate as in the full
handshake that created the session that is proposed for resumption
... and that is actually the behaviour which I implemented, and
what comes out naturally if you implement TLS extension SNI support
_outside_ of the TLS stack on the server side.

However, I believe that the server agreeing to resumption with a
different SNI hostname is a use case, that with a sensible
generic TLS client, should never actually occur in practice.
Except for bugs or design flaws in the client-side session cache management
maybe.

The client does _not_ know which TLS server certificates the server has
available, and what criteria it will apply for selecting one or the other.
The existence of a wildcard certificate does not unconditionally preclude
existence of host-specific certificates for specific services that are
technically covered by the wildcard.  I really dislike seemingly
non-deterministic behaviour, and therefore try to avoid it as much
as possible in whatever I implement.

The decision to accept a particular server certificate for one specific
hostname/target does not (should not) necessarily apply to *each* other
possible servername covered/conveyed by that server certificate.

Special-casing stuff makes the behaviour also difficult to comprehend
for end-users / consumers (and implementers get it wrong more easily).
What if the server certificate is "manually" confirmed by the end-user
(for whatever reason:  it's self-signed/untrusted or from DANE rather
that PKIX) should that "acceptance" still/also transcend to all other
hostnames (why or why not)?

My client-side TLS session cache management (which I implemented above
the TLS stack), uses the target hostname as one of the session cache
lookup parameters, and I don't think it would be sensible to propose
arbitrary sessions for resumption.

The performance overhead for a full handshake per hostname is completely
negligible (and if the server operator cares, he could simply avoid
spreading content over distinct server hostnames).

What I found painful instead, is the server-side behaviour implemented
by Microsoft IIS / SChannel in the past, because when configured for
optional client certificates, the server exhibits Alzheimer towards
certificate-less clients (or at least it did so in the past),
because it would force each client without client cert through
a full renegotiation handshake after resumption for each new connection,
failing to memorize that the resumed session was created by renegotiation
where the server did ask for a client cert and the client did turn down
that request.

-Martin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Oct 2016 12:41:26 -0500

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

On 10/24/2016 05:48 PM, Victor Vasiliev wrote:
> 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, *.cdn.example.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__cdn.example.com&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=t1O12kmBzZmXqHTSFe7DFW0i20d2hmZAgQxx-K8C4z4&e=>,
> and supplies a
> 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.]example.com 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).

> becoming confused.  On the server side, this requires implementations
> to know

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.

> 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

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).

-Ben

> On Thu, Oct 20, 2016 at 8:33 PM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     https://github.com/tlswg/tls13-spec/issues/720
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_issues_720&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=7Q2af7DaRnOwrSNMWkMfnKs9xHDrMn9HifdhztZCIks&e=>
>     I've added a statement
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcmarkup-3Fdoc-3D6066-23section-2D3&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=5EJDx9XlpTf2PkCnuN3iIVKBz8uwMCOQJpwV8fg9xK8&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_commit_b26093b5e9143fb61f5b619d1da78c4ba54b2121&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=ev2q8--tzpBkxa4aASjneoQ6WrW11JINJquDdDrhtos&e=>
>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__antoine.delignat-2Dlavaud.fr_doc_www15.pdf&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=bjOJibThsgQKY_v0SofUEncVF1EQMrI28rKnNqLupb8&e=>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=QlZQH8Ib1casHq6YFMriiZIPnTMzCHTxbPVrN_kDElI&s=I84l3Svs9XuDxebbvINR2b6XsvrDNJuv8tVrtr0Dw54&e=>
>
>
>
>

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 26 Oct 2016 14:11:06 -0400

On Wed, Oct 26, 2016 at 1:41 PM, Benjamin Kaduk <[email-masked]> wrote:

> I think it is useful to distinguish between this case, where [cdn.]
> example.com 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).
>
> may not have an easy way of knowing, in the absence of an explicit server
> signal as you propose.
>
>
I agree with your points, hence I have suggested explicit signal.  This is
more of a performance issue than a security issue, since resumption by
nature
requires the server to have access to the resumption key.

> trust anchors for each host.  In all of those cases, it is on the client
> to not
> 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
Web browsers already have to implement all of those policy filters for
HTTP/2
connection pooling, so I do not expect this to be that much of a burden to
implement.  Since the client can always choose to not send a ticket, it can
always decide to not resume across multiple domains in order to simplify the
implementation.

  -- Victor.