Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

[Stephen Farrell <[e-mail]>]

Hiya,

On 19/07/2021 16:21, Ryan Sleevi wrote:
> On Mon, Jul 19, 2021 at 11:02 AM Stephen Farrell <[e-mail]>
> 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? 

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 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.

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 a
> general 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?
>