On Tue, Nov 10, 2020 at 5:29 PM Victor Vasiliev <vasilvv= 40google....@dmarc.ietf.org> wrote:
> On Mon, Nov 9, 2020 at 11:51 PM Martin Thomson <m...@lowentropy.net> 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. > 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. > 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). > 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).
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
