I support adopting this draft. On Tue, Nov 10, 2020 at 5:38 PM Ryan Sleevi <ryan-ietf...@sleevi.com> wrote:
> 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. > Cross-site tracking mitigations in browsers are primarily focused on the top-level site, and partitioning state, like caches, based on that. That is, when the user visits https://a.example and separately on https://b.example, those two pages should not interfere with each other. The https://a.example and https://b.example loads may themselves make cross-origin requests, perhaps to the same origin, like https://common-3p-provider.example. But {common-3p-provider, a} and {common-3p-provider, b} live in different partitions, so those requests would not be allowed to share connections or TLS sessions. Where requests *are* in the same partition, this draft is still useful. Browsers are generally okay with two parts of the same page talking to each other. It's also worth noting that the cross-name resumption and cross-name HTTP/2 connection reuse have the same tracking power. In the browser context, even same-origin connection reuse has the same issue given cross-origin subresources. All of these are equally mitigated by top-site partitioning. 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). > Yeah, it's probably worth some generic sentence just so the layer above knows to deal with it. Although really this sentence should have been in RFC8446. Something to fix for rfc8446bis perhaps. Cross-name or not, two connections that share a TLS session cache can be correlated by the server. Client applications need to partition their TLS session cache to match their desired correlation boundaries. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
