Hiya,
On 19/07/2021 16:21, Ryan Sleevi 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 aresufficient?
I'm saying I don't know. I'm not a browser implementer. Nor are a bunch of other people who use TLS and who won't be familiar with fetch.
That is, this is the current language from the draft:For example, the Web use case uses network partition keys to separatecache 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.
The spec doesn't say how to mitigate the problem for any other application using TLS, nor does it explain how to mitigate the issue for a browser, other than via that one sentence referring to a document that can change (though that last isn't my problem with this spec). I don't myself know how well that mechanism mitigates the issue for browser users, nor how feasible it might be to do something similar in a non-browser. (If the mechanism works ok for browsers, that's fine for them of course.)
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,
It's very common to see web servers and MTAs on the same IP address, and also common to see the same certificate used for both. (My scans were of hosts listening on mail ports but I also scanned 443.)
but it's unclear if this is meant to be ageneral statement or specific to mail.
The scale issue is general I think. I agree that trackers today overwhelmingly enjoy the web as their preferred tool. But again, my fundamental issue with this is that we ought not be added new cross-domain tracking threats. S.
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?
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
