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

[Kazuho Oku <[e-mail]>]

kazuho 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

@ferrieux
> A PRNG is already needed for the spin bit's anonimity set, and for its fixed per-conneciton value when not spinning. A tiny increment, then, compared to the weight of version deployment for anybody willing to experiment with these "reserved" (should be called "frozen") bits.

Runtime overhead is the issue here; I do not think requiring endpoints to call CSPRNG for every packet they send is a good idea (note: use of non-cryptographically secure RNG is a way to leak PN). Re providing the freedom to "experiment", please see my comment below.

> While using the reserved bits (which were designed for exactly this) is clearly the most efficient way for on-path signalling (no overhead ; same-tuple ; sync with flow).

While I do not think reserved bits are "designed" for on-path signaling, I agree that it is a convenient way for exposing signals.

The trade-off here is if we want to pay the extra cost of calling CSPRNG for every packet we send, to provide the endpoints to use the bits exposing information to on-path devices without peers' consent.

@igorlord
> However, an endpoint that is not trying to leak information and is just tagging packets for VEC or Loss detection or other operational purpose would find these bits a lot more convenient. That said, 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).

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. Protecting the bits under header protection is the easiest way to guarantee that.

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