3 ms·

Coincidentally came across this while looking up a board game: "The hidden costs of QUIC and TOU" https://www.snellman.net/blog/archive/2016-12-01-quic-tou/ htt

Coincidentally came across this while looking up a board game: "The hidden costs of QUIC and TOU" https://www.snellman.net/blog/archive/2016-12-01-quic-tou/ https://www.snellman.net/blog/archive/2016-12-01-quic-tou/

jsnell 9y ago
While I still stand behind what was written in that post re: the non-endpoints needing the ability to troubleshoot networks, it might not be totally up to date. A caricature of the stakeholders in QUIC standardization would split them in three groups: - The privacy cabal thinks that every single bit of unencrypted data is unacceptable, since with enough statistical evidence over enough data paths it could be used to deduce some bit of totally irrelevant information about a user. - The operator cabal believes that any bit of encrypted metadata (but not payload data) is unacceptable, since there could be some valid operational reason to access it. - The ossification cabal believes that any bit of unencrypted data is unacceptable, since somebody in the operator cabal would end up misusing it, and accidentally fix the protocol in place. Now, obviously actual humans are more nuanced than that. Still, at the time that was written, it appeared that there was absolutely no chance of getting any manageability metadata at all. These are not positions conducive to compromise. (And the lack of that kind of data leads to horrible things like using the TCP traffic going to client X to infer measurements on the QUIC traffic going to the same client). But at the moment it feels like it might be possible (but nowhere near guaranteed) for the standardization to export some minimal amount of transport layer data. See for example the spin-bit proposal [0], where just 1-2 bits of incredibly non-sensitive data would already go a long way. Give me a single spin-bit and say 3 low-order bits of the packet number, and I'd be happy. [0] https://tools.ietf.org/html/draft-trammell-quic-spin-01 https://tools.ietf.org/html/draft-trammell-quic-spin-01

jsnell 9y ago

While I still stand behind what was written in that post re: the non-endpoints needing the ability to troubleshoot networks, it might not be totally up to date. A caricature of the stakeholders in QUIC standardization would split them in three groups: - The privacy cabal thinks that every single bit of unencrypted data is unacceptable, since with enough statistical evidence over enough data paths it could be used to deduce some bit of totally irrelevant information about a user. - The operator cabal believes that any bit of encrypted metadata (but not payload data) is unacceptable, since there could be some valid operational reason to access it. - The ossification cabal believes that any bit of unencrypted data is unacceptable, since somebody in the operator cabal would end up misusing it, and accidentally fix the protocol in place. Now, obviously actual humans are more nuanced than that. Still, at the time that was written, it appeared that there was absolutely no chance of getting any manageability metadata at all. These are not positions conducive to compromise. (And the lack of that kind of data leads to horrible things like using the TCP traffic going to client X to infer measurements on the QUIC traffic going to the same client). But at the moment it feels like it might be possible (but nowhere near guaranteed) for the standardization to export some minimal amount of transport layer data. See for example the spin-bit proposal [0], where just 1-2 bits of incredibly non-sensitive data would already go a long way. Give me a single spin-bit and say 3 low-order bits of the packet number, and I'd be happy. [0] https://tools.ietf.org/html/draft-trammell-quic-spin-01 https://tools.ietf.org/html/draft-trammell-quic-spin-01