Re: [tcpm] Privacy problems of TCP Fast Open

[Olivier Bonaventure <[e-mail]>]

Michael, Brian,

>>> 
>>> 
>> 
>> You're correct to point out that 0RTT resumption is and will always remain special, not only due to the special requirements it places on applications but also for cryptographic reasons (0RTT cannot be made forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). 
>> 
>> ISTM there are the following possibilities:
>> 
>> (1) Do nothing.
>> 
>> (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO cookies are traceable, and should be avoided in the open Internet when 
>> 
>> (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain the privacy reason behind the deprecation in the deprecated document.
>> 
>> (3) Update TFO to make TFO cookies optional, and explain the tradeoffs.
>> 
>> I would expect pushback on 2 or 3 from people running TFO on the Internet, because it requires coordinated implementation effort and changes the operational environment (which always carries risk).
> 
> Why would 3 require coordinated implementation effort?
> Just to make sure we’re on the same page, I’m proposing to allow handing over data from the SYN directly (with all the needed caveats and warnings), even when there’s no TFO option in place.

During the Prague meeting, Christoph Paasch explained that this approach is already used by a specific application. The 0-rtt convert protocol also proposes to use this approach.

> If a server doesn’t support this yet, it takes an RTT longer. If a client doesn’t support this yet (and hence only puts in data on a SYN *with* the TFO option), nothing bad happens, except that there are the privacy concerns that kicked off this thread. When a client doesn’t support this and does *not* put data on a SYN, nothing special happens. This seems like a good gradual upgrade path for me.
> Regarding front-ends, I guess they could make rejection decisions when they see too many SYNs carrying data with or without a TFO option.

I agree, there are various techniques to deal with DoS attacks on a stack and inside specialised protocols.
> 
> Perhaps this also answers Michael Tuexen’s comment about  https://tools.ietf.org/html/rfc7413#section-7.3 <https://tools.ietf.org/html/rfc7413#section-7.3>  - which has similarities, but:
> - the first paragraph sounds a bit too limiting: I mean this as a general use thing, just like TFO, only with the caveat of having to limit the load somehow… e.g. limit how many of these messages-on-SYNs an app processes per second.
> - the second paragraph is in conflict with what I’m proposing: it talks about generating "a trivial or even a zero-length cookie” and switching to regular TFO as a fall-back. I’m proposing operation without a TFO option; just relax the “how to process data from SYN” rule and state all the necessary warnings.
> 
> 
>> There is the caveat that I'm not sure how many are running TFO on the Internet. (I do know Google was the biggest one, at least a couple of years ago, from research I did before joining).
> 
> Yep, that too… just relaxing the “how to process data-on-SYN" rule seems easier to deploy.
> 

RFC793 authorises data in the SYN and Christoph’s explanation shows that today SYN with data but without TFO option pass through more paths than SYN with data but with a TFO option


Olivier



-- 


Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>