4 ms·

>"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO." Could you or someone else say what are the privacy issues a

>"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO." Could you or someone else say what are the privacy issues are with QUIC?

1vuio0pswjnm7 4y ago
See Section 7 of RFC 9250 that is the subject of this submission. QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.
- mritun 4y ago
  Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship? QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.
  - bogomipz 4y ago
    Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that: >"The cryptography is based off TLS 1.3 and to prevent ossification ..." I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?
    - mritun 4y ago
      The transport protocol is UDP however the security layer is basically TLS 1.3.
- 1vuio0pswjnm7 4y ago
  From a "privacy against companies like Google perspective", QUIC does not have a good track record so far with respect to its use for HTTP. The prioritisation of censorship resistence is evident in its design however a similar prioritisation for resistance to personal data collection and tracking by companies associated with online advertising, such as Google, is not. https://www.theregister.com/2021/01/30/quic_fingerprinting_flaw/ https://www.theregister.com/2021/01/30/quic_fingerprinting_f... https://arxiv.org/pdf/2101.11871 https://arxiv.org/pdf/2101.11871 (Non-substantive) discussion: https://news.ycombinator.com/item?id=25969886 https://news.ycombinator.com/item?id=25969886 As an avid TLS1.3 (with ESNI for all Cloudflare sites) user, I noticed QUIC did not try to avoid sending a hostname in plain text over the wire. They could have, but they did not. There is also the issue of unnecessary HTTP headers such as User-Agent. I filter out unnecessary header in a forward TCP/HTTP proxy. How would one do this if using QUIC. Privacy issues of ISPs in the modern web "This is the case of QUIC, designed by Google and implemented in Google Chrome, Android smartphones as well as on Google Web servers. It relies on UDP and provides authentication and confidentiality for HTTP transactions. Nevertheless, the server hostname is transmitted in clear, posing the same privacy issues of TLS. Moreover, QUIC transmits clients User-Agent in clear, unveiling users device type." https://core.ac.uk/download/pdf/234919911.pdf https://core.ac.uk/download/pdf/234919911.pdf Anyway, the potential for tracking was evident early on. A QUIC Look at Web Tracking Proceedings on Privacy Enhancing Technologies ; 2019 (3):255266 "Our analysis reveals that the protocol design contains violations of privacy best practices through which a tracker can passively and uniquely identify clients across several connections. This tracking mechanisms can achieve reduced delays and bandwidth requirements compared to conventional browser fingerprinting or HTTP cookies. This allows them to be applied in resource- or time-constrained scenarios such as real-time biddings in online advertising." https://petsymposium.org/2019/files/papers/issue3/popets-2019-0046.pdf https://petsymposium.org/2019/files/papers/issue3/popets-201... The efforts being made to reduce that potential have been unconvincing. This is not the padding you are looking for! On the ineffectiveness of QUIC PADDING against website fingerprinting "To provide protection against traffic analysis [. . . ], the working group behind QUIC, the next transport layer standard for the Web, introduced a PADDING frame in the specification [11]. In this work, we demonstrate that defenses solely based on padding QUIC traffic are ineffective against WF attacks." https://eprint.iacr.org/2015/582.pdf https://eprint.iacr.org/2015/582.pdf Now, years later we are presented with the proposition of using QUIC for DNS. From the Section 7 of RFC 9250 that is the subject of this HN submission: "The recommendation for TLS 1.3 [RFC8446] is that the capability to use 0-RTT data should be turned off by default and only enabled if the user clearly understands the associated risks. In the case of DoQ, allowing 0-RTT data provides significant performance gains, and there is a concern that a recommendation to not use it would simply be ignored." The authors of this RFC 9250 claim they refuse to recommend turning off 0-RTT by default because (a) 0-RTT and session resumption provide performance gains and (b) they speculate any such recommendation would be ignored. Neither are adequate justifications. The problem with (a) as a justification is that the tradeoff is not simply between performance and privacy it is between privacy and commercial gain. The later can be achieved by subjugating user privacy in order to perform data collection and tracking to support the commercial interests of companies that profit from the proliferation of online advertising. The problem with (b) as a justification is that 1. it is pure speculation (in fact, there is evidence to the contrary - see below) and 2. the same speculation is not applied to Section 4.5. How does a user verify that a server is following Section 4.5. Even if we give the RFC authors our absolute blind faith trust that they have DNS user privacy interests as their top priority, it is still clear that they are prioritising performance gains over privacy risks. It stands to reason that they would be motivated to do so because the only legitimate way DoQ can win adoption over the (less risky) alternatives is if it offers better performance. One to Rule them All? A First Look at DNS over QUIC https://doi.org/10.1007/978-3-030-98785-5_2 https://doi.org/10.1007/978-3-030-98785-5_2 "Finally, none of the DoQ-verified resolvers offer support for QUIC 0-RTT. However, the lack of 0-RTT support might be a deliberate choice, as the use of 0-RTT exposes clients to privacy risks." [The authors recently tested 1,217 DoQ-verified resolvers found on the internet in January 2022.] https://arxiv.org/pdf/2202.02987 https://arxiv.org/pdf/2202.02987

>"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO." Could you or someone else say what are the privacy issues are with QUIC?

1vuio0pswjnm7 4y ago

See Section 7 of RFC 9250 that is the subject of this submission. QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.

mritun 4y ago
Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship? QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.
- bogomipz 4y ago
  Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that: >"The cryptography is based off TLS 1.3 and to prevent ossification ..." I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?
  - mritun 4y ago
    The transport protocol is UDP however the security layer is basically TLS 1.3.
1vuio0pswjnm7 4y ago
From a "privacy against companies like Google perspective", QUIC does not have a good track record so far with respect to its use for HTTP. The prioritisation of censorship resistence is evident in its design however a similar prioritisation for resistance to personal data collection and tracking by companies associated with online advertising, such as Google, is not. https://www.theregister.com/2021/01/30/quic_fingerprinting_flaw/ https://www.theregister.com/2021/01/30/quic_fingerprinting_f... https://arxiv.org/pdf/2101.11871 https://arxiv.org/pdf/2101.11871 (Non-substantive) discussion: https://news.ycombinator.com/item?id=25969886 https://news.ycombinator.com/item?id=25969886 As an avid TLS1.3 (with ESNI for all Cloudflare sites) user, I noticed QUIC did not try to avoid sending a hostname in plain text over the wire. They could have, but they did not. There is also the issue of unnecessary HTTP headers such as User-Agent. I filter out unnecessary header in a forward TCP/HTTP proxy. How would one do this if using QUIC. Privacy issues of ISPs in the modern web "This is the case of QUIC, designed by Google and implemented in Google Chrome, Android smartphones as well as on Google Web servers. It relies on UDP and provides authentication and confidentiality for HTTP transactions. Nevertheless, the server hostname is transmitted in clear, posing the same privacy issues of TLS. Moreover, QUIC transmits clients User-Agent in clear, unveiling users device type." https://core.ac.uk/download/pdf/234919911.pdf https://core.ac.uk/download/pdf/234919911.pdf Anyway, the potential for tracking was evident early on. A QUIC Look at Web Tracking Proceedings on Privacy Enhancing Technologies ; 2019 (3):255266 "Our analysis reveals that the protocol design contains violations of privacy best practices through which a tracker can passively and uniquely identify clients across several connections. This tracking mechanisms can achieve reduced delays and bandwidth requirements compared to conventional browser fingerprinting or HTTP cookies. This allows them to be applied in resource- or time-constrained scenarios such as real-time biddings in online advertising." https://petsymposium.org/2019/files/papers/issue3/popets-2019-0046.pdf https://petsymposium.org/2019/files/papers/issue3/popets-201... The efforts being made to reduce that potential have been unconvincing. This is not the padding you are looking for! On the ineffectiveness of QUIC PADDING against website fingerprinting "To provide protection against traffic analysis [. . . ], the working group behind QUIC, the next transport layer standard for the Web, introduced a PADDING frame in the specification [11]. In this work, we demonstrate that defenses solely based on padding QUIC traffic are ineffective against WF attacks." https://eprint.iacr.org/2015/582.pdf https://eprint.iacr.org/2015/582.pdf Now, years later we are presented with the proposition of using QUIC for DNS. From the Section 7 of RFC 9250 that is the subject of this HN submission: "The recommendation for TLS 1.3 [RFC8446] is that the capability to use 0-RTT data should be turned off by default and only enabled if the user clearly understands the associated risks. In the case of DoQ, allowing 0-RTT data provides significant performance gains, and there is a concern that a recommendation to not use it would simply be ignored." The authors of this RFC 9250 claim they refuse to recommend turning off 0-RTT by default because (a) 0-RTT and session resumption provide performance gains and (b) they speculate any such recommendation would be ignored. Neither are adequate justifications. The problem with (a) as a justification is that the tradeoff is not simply between performance and privacy it is between privacy and commercial gain. The later can be achieved by subjugating user privacy in order to perform data collection and tracking to support the commercial interests of companies that profit from the proliferation of online advertising. The problem with (b) as a justification is that 1. it is pure speculation (in fact, there is evidence to the contrary - see below) and 2. the same speculation is not applied to Section 4.5. How does a user verify that a server is following Section 4.5. Even if we give the RFC authors our absolute blind faith trust that they have DNS user privacy interests as their top priority, it is still clear that they are prioritising performance gains over privacy risks. It stands to reason that they would be motivated to do so because the only legitimate way DoQ can win adoption over the (less risky) alternatives is if it offers better performance. One to Rule them All? A First Look at DNS over QUIC https://doi.org/10.1007/978-3-030-98785-5_2 https://doi.org/10.1007/978-3-030-98785-5_2 "Finally, none of the DoQ-verified resolvers offer support for QUIC 0-RTT. However, the lack of 0-RTT support might be a deliberate choice, as the use of 0-RTT exposes clients to privacy risks." [The authors recently tested 1,217 DoQ-verified resolvers found on the internet in January 2022.] https://arxiv.org/pdf/2202.02987 https://arxiv.org/pdf/2202.02987