Subject: [TLS] Call for adoption of draft-vvv-tls-cross-sni-resumption

From: Joseph Salowey <[email-masked]>
Date: Mon, 9 Nov 2020 19:44:27 -0800

Based on interest and support expressed at IETF 108, this email starts the
call for adoption of draft-vvv-tls-cross-sni-resumption. The draft can be
found here:

   https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00

This adoption call will run until November 30, 2020. Please indicate
whether or not you would like to see this draft adopted. Note that this is
an adoption call for the draft as a starting point towards solving the
problem of resumption across SNI values. The final mechanism may certainly
change depending on related efforts, e.g., draft-ietf-tls-tlsflags.

Thanks,

Sean, Chris and Joe

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Nov 2020 15:50:29 +1100

I've no objection to adopting this, though I will note that it is likely of minimal use in the browser context due to the move to isolated storage (which includes tickets).  The potential value for cross-origin connections on the same page exists, but it would be good to understand whether the advantages seen are significant enough to justify the effort and complication involved.

Thus, the draft needs to include privacy considerations, particularly regarding cross-origin tracking.  I am also of the opinion that it should use flags, but that would depend on changes to the flags draft.

On Tue, Nov 10, 2020, at 14:44, Joseph Salowey wrote:
>  
> Based on interest and support expressed at IETF 108, this email starts 
> the call for adoption of draft-vvv-tls-cross-sni-resumption. The draft 
> can be found here:
> 
> 
> 
> whether or not you would like to see this draft adopted. Note that this 
> is an adoption call for the draft as a starting point towards solving 
> the problem of resumption across SNI values. The final mechanism may 
> certainly change depending on related efforts, e.g., 
> draft-ietf-tls-tlsflags.
> 
> 
> 
> Thanks,
> 
> 
> 
> Sean, Chris and Joe
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2020 11:05:59 +0000

Hiya,

On 10/11/2020 03:44, Joseph Salowey wrote:
> whether or not you would like to see this draft adopted.

I'd be more in the "not yet" bracket for this. As Martin
mentions this'd seem to create a possibly attractive way
to do more tracking, so I think we ought try understand
how that might fit into the wider set of new things (e.g.
the HTTPS RRtype) before adopting.

One concern is that this mechanism plus some minimal cert
trickery such as having a single name present in many certs
could result in large scale cross domain tracking if say the
owner of "use-us-to-track-em.example.com" enabled anyone in
their (advertising) network to pass ACME checks as needed,
for that name.

While that kind of trickery ought be visible via CT, I'm not
sure we could depend on the web PKI to ensure it'd not
happen.

Cheers,
S.

> Note that this is

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Nov 2020 08:29:23 +1100

> the HTTPS RRtype) before adopting.

I said something different.  A subtle distinction perhaps, but an important one.  I said that tracking protections could render this inoperative/ineffective.  You seem to be saying something else, which is that you don't trust people to deploy this responsibly.

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 10 Nov 2020 17:28:34 -0500

On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson <[email-masked]> wrote:

> I've no objection to adopting this, though I will note that it is likely
> of minimal use in the browser context due to the move to isolated storage
> (which includes tickets).  The potential value for cross-origin connections
> on the same page exists, but it would be good to understand whether the
> advantages seen are significant enough to justify the effort and
> complication involved.
>

That's fine, since in most of the cases where this is useful the top-level
origin is the same.

> Thus, the draft needs to include privacy considerations, particularly
> regarding cross-origin tracking.  I am also of the opinion that it should
> use flags, but that would depend on changes to the flags draft.
>

I considered that.  This particular attack seems to be fairly web-specific,
and since the mitigation (network partition keys
<https://fetch.spec.whatwg.org/#network-partition-keys>) relies heavily on
Web concepts, I'm not sure a TLS draft would be a good place for describing
it (compared to, say, Fetch).

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 11 Nov 2020 09:37:20 +1100

On Wed, Nov 11, 2020, at 09:28, Victor Vasiliev wrote:
> I considered that.  This particular attack seems to be fairly 
> web-specific, and since the mitigation (network partition keys 
> <https://fetch.spec.whatwg.org/#network-partition-keys>) relies heavily 
> on Web concepts, I'm not sure a TLS draft would be a good place for 
> describing it (compared to, say, Fetch).

A one sentence reminder that using this capability allows for transfer of information between what might otherwise be isolated server identities is all I'm asking for.  I'm not asking for a full breakdown of storage isolation and fetch integration, just the hooks that would ensure that people know to think about this problem.  Browsers are probably amply covered in this regard, but the problem exists more generally.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 10 Nov 2020 17:38:27 -0500

> That's fine, since in most of the cases where this is useful the top-level

Can you expand on this? You seem to be describing a situation to allow
resumption when the origins are different (cross-hostname), but then state
this is fine, because the top-level origin is the same.

> describing it (compared to, say, Fetch).

It's not immediately obvious how this concern is web-specific. Cross-host
linkability seems relevant regardless of whether the Web is involved, as
it's fundamentally a question about whether or not two hosts are seen as
part of the same effective logical group/administrative domain or not, even
if they might share operational characteristics (e.g. the same certificate,
the same CDN).

---

From: David Benjamin <[email-masked]>
Date: Tue, 10 Nov 2020 18:20:48 -0500

I support adopting this draft.

On Tue, Nov 10, 2020 at 5:38 PM Ryan Sleevi <[email-masked]> wrote:

>> That's fine, since in most of the cases where this is useful the
>> top-level origin is the same.
>>
>

Cross-site tracking mitigations in browsers are primarily focused on the
top-level site, and partitioning state, like caches, based on that. That
is, when the user visits https://a.example and separately on
https://b.example, those two pages should not interfere with each other.
The https://a.example and https://b.example loads may themselves make
cross-origin requests, perhaps to the same origin, like
https://common-3p-provider.example. But {common-3p-provider, a}
and {common-3p-provider, b} live in different partitions, so those requests
would not be allowed to share connections or TLS sessions.

Where requests *are* in the same partition, this draft is still useful.
Browsers are generally okay with two parts of the same page talking to each
other.

It's also worth noting that the cross-name resumption and cross-name HTTP/2
connection reuse have the same tracking power. In the browser context, even
same-origin connection reuse has the same issue given cross-origin
subresources. All of these are equally mitigated by top-site partitioning.

> if they might share operational characteristics (e.g. the same certificate,

Yeah, it's probably worth some generic sentence just so the layer above
knows to deal with it. Although really this sentence should have been in
RFC8446. Something to fix for rfc8446bis perhaps. Cross-name or not, two
connections that share a TLS session cache can be correlated by the server.
Client applications need to partition their TLS session cache to match
their desired correlation boundaries.

David

---

From: Victor Vasiliev <[email-masked]>
Date: Mon, 23 Nov 2020 15:04:22 -0500

Hi Martin,

I wrote up a PR directly discussing this issue:
https://github.com/vasilvv/tls-cross-sni-resumption/pull/1

Does this address your concern?

On Tue, Nov 10, 2020 at 5:37 PM Martin Thomson <[email-masked]> wrote:

> A one sentence reminder that using this capability allows for transfer of
> information between what might otherwise be isolated server identities is
> all I'm asking for.  I'm not asking for a full breakdown of storage
> isolation and fetch integration, just the hooks that would ensure that
> people know to think about this problem.  Browsers are probably amply
> covered in this regard, but the problem exists more generally.
>

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 30 Nov 2020 19:20:04 -0800

At this point we do not have many responses and it is not clear if there is
consensus to adopt the draft.  Given that this call has overlapped with
vacation time we are going to extend the call until December 11, 2020.
Please indicate if you are willing to be a reviewer for the draft.

Thanks,

Sean, Chris and Joe