Re: [quicwg/base-drafts] First byte changes (#2006)

[Igor Lubashev <[e-mail]>]

igorlord commented on this pull request.



>  
-: The fourth bit (0x10) of byte 0 is set to 1.
+: The next two bits (those with a mask of 0x18) of byte 0 are reserved.  These
+  bits are protected using header protection (see Section 5.4 of
+  {{QUIC-TLS}}).  The value included prior to protection MUST be set to 0.  An

@kazuho 
> > I understand the concern about some inadvertent disclosure by a poorly designed experiment (if this is the concern).
> 
> Yes. That is exactly the concern. Remember that we were uncertain about the privacy concerns of the spin bit for very long time (IIRC the risk of exposing the latency of the hidden path behind a VPN was brought up pretty recently).

The extensive analysis of a _specific_ protocol behavior prescribed by a standard was well-advised, indeed. It allowed people to make an informed decision of whether to implement that specific behavior, and different implementers will choose differently.

> I think that we should allow endpoints to use the bits for exposing information only when extensive privacy analysis has been done and the WG is convinced.

Since there is no question about any specific standard purpose to consider for these bits, this concern looks different to me.  It is rather akin to "do not touch anything not approved by us -- the WG -- or you may leak something". There are plenty of ways a sender can "leak something" to the path: IP ID field / IPv6 Flow Label selection, TTL/HopLimit fields, DS/ECN fields, packet size choices, packet timings, congestion avoidance behaviors, etc.  In this light, "we do not trust you with _these_ bits" seems more effective at complicating operational experimentation than at protecting privacy.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2006#discussion_r234841333