Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

[David Benjamin <[e-mail]>]

I'll add that, in the context of cross-domain tracking on the web, this
draft is a red herring. Remember that web pages have subresources. That
means looking at the destination domain isn't useful because two different
pages can embed a common destination domain. So the same concerns exist
with RFC8446 (TLS resumption), RFC7540 (connection-reuse, same- and
cross-domain), and RFC7230 (connection reuse). That's why we need a
holistic answer like network partition keys from [FETCH], that apply to
*all* network state. That answer applies equally to plain resumption and
this draft.

Of course, [FETCH] doesn't apply to other applications, just the web. But I
think the above should demonstrate that correlation boundaries are
necessarily a whole-application question. That's why the [FETCH] citation
is only an example. The general guidance is this:

> Client applications should partition the session cache between
connections that are meant to be uncorrelated.

This applies to all application protocols. Do you believe your correlation
boundary is an individual email? Well, you shouldn't reuse any state across
those and probably will end up not doing any resumption at all. Do you have
multiple contexts in your application, like different profiles, that are
meant to be separate? Well, you shouldn't reuse state across those
profiles. Does your application not have correlation boundaries? Well, then
you can resume whatever. Are you a non-web application where partitioning
by just the destination domain is meaningful? Well, then you should
partition your session cache accordingly, which no-ops this extension and
parts of RFC7540.

Indeed, since this is a general problem with TLS resumption, we're really
talking about an omission in RFC8446 itself. For rfc8446bis, I landed this
PR, which corrects the omission.
https://github.com/tlswg/tls13-spec/pull/1205
Were publication orders different, there would be no need to include the
same text in draft-ietf-tls-cross-sni-resumption, but so it goes.

On Mon, Jul 19, 2021 at 11:22 AM Ryan Sleevi <[e-mail]>
wrote:

>
>
> On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <
> [e-mail]> wrote:
>
>> I don't find the reference to [FETCH] explains how that
>> problem can be mitigated by browsers. (IIRC, adding that
>> was the result of earlier discussion of this point?)
>>
>
> I'm not sure I'm parsing this correctly.
>
> Are you saying that you don't believe network isolation keys are
> sufficient? That is, this is the current language from the draft:
>
> > For example, the Web use case uses network partition keys to separate
> cache lookups [FETCH].
>
> And the term there ("network partition keys") is a defined term in the
> FETCH spec that forms the basis of cross-domain tracking prevention:
> https://fetch.spec.whatwg.org/#network-partition-key
>
> It's unclear whether you're saying that the spec should diverge from FETCH
> and impose additional requirements, or whether you're saying you don't
> believe the current FETCH spec is robust enough there.
>
> It's unclear that there's any benefit to having the Cross-SNI spec impose
> additional requirements: you have to consider the Web application in its
> entire context, which is precisely what network partition keys do.
> Similarly, if the concern is that FETCH isn't sufficient for your concerns,
> is that a concern with this spec, or with FETCH, and can/should they be
> articulated there (and the related issue mentioned)
>
> <snip>
>
>> I think both of those are indicators that this mechanism
>> could be used at scale for tracking.
>>
>
> You opened by talking about MTAs, but it's unclear if this is meant to be
> a general statement or specific to mail. In the context of the Web, then we
> have to consider the holistic platform, and ask whether this hooks into the
> same appropriate points - it does, as the partition keys are based on the
> same cross-origin tracking protection mechanisms (e.g. the determination of
> "first party" vs "third party" contexts is implicitly handled here). If
> this is for mail, then isn't the point that this remains an
> application-/protocol-specific consideration?
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>