IESG review Paul Wouters: Section 2 - fallback
Closed this issue · 2 comments
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.
This sentence is a bit tricky to read and could use a rewrite. But I'm also not sure of the meaning. I understand that with TCP you can send RST packets to kill it, and with UDP you cannot. But with UDP you can also send equivalent to RST packets. For instance I have observed responses to UDP based IKEv2 packets causing IKEv2 communication to completely fail (where the MITM replies before the real target). Does QUIC really prevent all of this, because that is what the sentence seems to suggest by pointing out specific flaws in the "fallback option" to QUIC.
I am not sure if ALPN leakage would qualify as "significantly weaker cryptographic protection". I don't see much multiplexing usin ALPN, so the port number is still kind of a dead giveaway for the application being used anyway.
I've sent a reply with some explanation to Paul by email and waiting for a response now.
For the record, this is what I'm sent in mail:
"[MK] I think you are overinterpreting this. All this sentence is supposed to say that if you use TCP/TLS, this will expose more information (in the TCP header) than what is exposed with QUIC and also the TCP is not protected at all, so maybe be manipulated. We didn't even really think about any RST attacks here and really didn't want to discuss that level of detail. It's just a statement of fact to create awareness. It's not any kind of recommendation to use this fallback or not. Do we need to be more clear? However, not quite sure what else we should actually say..."
Closing with no action now...