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
