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 <ryan-ietf...@sleevi.com> wrote: > > > On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell < > stephen.farr...@cs.tcd.ie> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
