Git archive generation meets Hyrum's law

Posted Feb 10, 2023 11:59 UTC (Fri) by Lennie (subscriber, #49641)
In reply to: Git archive generation meets Hyrum's law by zdzichu
Parent article: Git archive generation meets Hyrum's law

The new QUIC protocol has adopted a similar strategy, quote from some one who wrote about it: "To prevent ossification, QUIC tries to encrypt as much data as possible, including signaling information [10], to hide it from network equipment and prevent vendors of said equipment from making assumptions that will interfere or prevent future changes to the protocol."

Git archive generation meets Hyrum's law

Posted Feb 10, 2023 12:58 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

And for the bits in the unencrypted header, that is effectively fixed to 1, there is even an RFC to allow QUIC end-points to negotiate (in the somewhat encrypted handshake) deliberately twiddling that bit deliberately - see RFC9287, https://www.rfc-editor.org/rfc/rfc9287.html .

Which really means that bit shouldn't have been there in the header, probably.

Git archive generation meets Hyrum's law

Posted Feb 10, 2023 15:02 UTC (Fri) by wsy (subscriber, #121706) [Link] (1 responses)

For people living in dystopian countries, such a bit is frustrating. We need a protocol that's widely used by legit websites while indistinguishable from anti-censorship tools.

Git archive generation meets Hyrum's law

Posted Feb 10, 2023 15:27 UTC (Fri) by paulj (subscriber, #341) [Link]

Well, the unencrypted QUIC header is pretty much inscrutable to middle-boxes. There is very little information in it, besides a few bits and a "Connection Identifier" (CID), but the end-points rotate the CID regularly.

Even the CID can be left out (and, to be honest, I think the unencrypted CID is a wart - the rotation of it adds a /lot/ of complications to QUIC, including hard to fix races).