Subject: [TLS] Removing restriction on cross-domain resumption

From: Victor Vasiliev <[email-masked]>
Date: Wed, 13 Sep 2017 17:57:21 -0400

Currently, TLS 1.3 specification forbids resuming the session if SNI values
do not match.  This is inefficient in multiple cases, for example, if you
have a wildcard domain cert, and the user is likely to visit multiple
subdomains over a longer timespan, so there is no existing connection to
pool on (or it's impossible to pool because of different IP addresses).

Last time we discussed this,
  https://www.ietf.org/mail-archive/web/tls/current/msg21655.html
no one has pointed out a good security reason why this should be
forbidden.  Also, the requirement as stated requires the server to enforce
it, while in reality, most implementations I am familiar with offload the
burden to the clients.

I wrote the following PR to remove the requirement:
  https://github.com/tlswg/tls13-spec/pull/1080
The PR still discourages clients to resume across domains by default (due
to likelihood of wasting a ticket which could have came in handy later), so
I'm currently writing a draft for an extension to inform clients that it's
okay to do that (it will be in spirit of PR #777
<https://github.com/tlswg/tls13-spec/pull/777>).

  -- Victor.

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 14 Sep 2017 15:10:27 -0700

We something like this today with QUIC's custom crypto handshake and it has
proven to be extremely useful. I can't wait to do this with TLS!

On Wed, Sep 13, 2017 at 2:57 PM, Victor Vasiliev <[email-masked]> wrote:

> Currently, TLS 1.3 specification forbids resuming the session if SNI
> values do not match.  This is inefficient in multiple cases, for example,
> if you have a wildcard domain cert, and the user is likely to visit
> multiple subdomains over a longer timespan, so there is no existing
> connection to pool on (or it's impossible to pool because of different IP
> addresses).
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 14 Sep 2017 18:42:33 -0400

On Wed, Sep 13, 2017 at 5:57 PM, Victor Vasiliev <[email-masked]> wrote:
> no one has pointed out a good security reason why this should be forbidden.

The current models uses origins as a boundary, so they are different
security contexts.

A related twist is, the boundary is established at layer 7, but layer
3/4 has no knowledge of it.

The DBOUND working group was not able to produce a deliverable. There
is no general purpose way to establish those boundaries.

To play devil's advocate, will the TLS stack need to keep a copy of
the certificate or authorized origins (an origin group?) for future
connections?

Jeff

---

From: David Benjamin <[email-masked]>
Date: Thu, 14 Sep 2017 23:03:57 +0000

> the certificate or authorized origins (an origin group?) for future

Implementations that don't retain enough information for it can always just
not offer sessions across domains. What resumption patterns to support and
what state to retain to support those is an implementation decision.

But stacks I've seen already retain this anyway. It's common to have APIs
that retrieve the peer certificate and for resumption to be more-or-less
transparent. That combination implies sessions must retain the peer
certificate to resurface when asked.

David

---

From: Martin Thomson <[email-masked]>
Date: Sat, 23 Sep 2017 11:15:52 +1000

> The current models uses origins as a boundary, so they are different

That's not relevant here.  A certificate allows a server to speak for
multiple origins.  The notion of an origin is, as you say, established
at a higher layer.  TLS establishes a broader notion of identity.

If you are interested in what origins a server might be authoritative
for and how those might be managed, see
http://httpwg.org/http-extensions/origin-frame.html

---

From: Jeffrey Walton <[email-masked]>
Date: Sat, 23 Sep 2017 01:14:51 -0400

> at a higher layer.  TLS establishes a broader notion of identity.

As far as I know, the IETF does not forbid inclusion of logically or
administratively disjoint hosts from a certificate. In a shared
hosting environment with a super cert, it seems like it would be easy
to confuse a user agent into binding the wrong name.

The IETF does not forbid an IP address either, so it seems like IP
addresses could be a sore spot, too.

And the hosting provider could pass the customary checks, like DV
emails. So there does not seem to be a security control available to
contain the risk.

Jeff