On 5/10/2023 7:35 PM, Lucas Pardue wrote:
Hey Tommy,
On Thu, May 11, 2023 at 3:00 AM Tommy Pauly<[email protected]> wrote:
The document is describing how bits*could* be used, not actually
suggesting reserving specific ones at this point.
This same feedback did come up in IESG review, and I believe that there
will be an update to remove details that refer to specific bit ranges to
avoid this danger.
I’ll let the authors chime in more =)
To summarize the issue, there's only 7 bits that any QUIC version
compatible with the Invariants can ever use. Unless client, server and
observers all agree what those bits might mean, there's no way to actually
use them assuredly. The draft doesn't pay enough attention to highlighting
this deployment problem, so there's a risk that the work done to define the
bits in the abstract is for nought because the next steps of trying this
out for real are unclear. Relying on some private agreements of what the
bits might mean isn't safe for several reasons.
I addition to Lucas' concerns, let me express my own concern with the
mention of the "UDP surplus space". This is the same concern that I have
with the proposal to define "UDP options". These options would define an
unencrypted trailer of QUIC packet. The idea is that the IP packet
length is longer than UDP header length plus UDP payload length, leaving
bits at the end that are not covered by the QUIC encryption. These bits
create a clear text "side channel", which can be easily used to
compromise the security of QUIC. I think this a serious security hole,
which should be blocked.
One way to block it is to immediately drop any QUIC packet for which IP
length and UDP length don't match. Many firewalls do that already. Doing
that will penalize any attempt to add a side channel to QUIC -- any
application that used such a channel would cause packets to be dropped,
making this kind of channels very unattractive.
-- Christian Huitema
