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

[Alexandre Ferrieux <[e-mail]>]

ferrieux 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 
> That means that endpoints (that do not have a way to "use" the bits) will be required to set them randomly. The issue here is that you need to randomize the bits separately, rather than just relying on header protection to randomize the bits. It is an unnecessary complexity.

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.

> > An endpoint can already disclose any and all info to anyone without peer's consent, and these bits are by far not the most convenient mechanism for such disclosures.
> 
> If that is the case, why do we need to care about the bits? If the endpoints have an easier way to expose the information, can't they just be randomized using header protection?

What Igor means, I think, is that the protection against unilateral disclosure of *anything* is negligible (for one, the endpoint could send unencrypted copies of the entire flow somewhere else). 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).


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