Complete version negotiation failure

[martinthomson]

It looks like this: Client supports A and B only. Server supports C and D only. Client sends initial in A (or B), server sends Version Negotiation in response. Client does what exactly? Might as well say.

We could get into the client maybe ignoring that because it's an attack, but we decided not to worry too much about that, so probably not worth saying.

[mikkelfj]

It's not (generally) an attack and it is a very possible because no-one supports the insecure A or B anymore (like TLS 1.0, 1.1). Client API returns the equivalent of 501 Not Implemented.

It could of course be an injected packet so the client could wait for something better to show up before failing.

No action required.

[mikkelfj]

" The client MUST choose the version that it most prefers from those supported by the server" ->
or abort the connection attempt with an error indicating that no supported version was available. A client MAY discard such a Version Negotion packet and wait a short while in order to mitigate injection attacks.

[martinthomson]

Yeah, all I'm looking for here is the "If the client does not support any of the versions the server offers, it aborts the connection attempt." bit you pointed at.

[mikkelfj]

I was about to do a PR, but the text is in your PR

[martinthomson]

Yep, I dumped it on top of that pile.

[igorlord]

@mikkelfj, trying to mitigate this injection DoS attack is much harder than merely "waiting a bit before failing". If your implementation waits a bit in case of no common version in VN packet, what would it do, if an attacker injects a VN packet with a version you do support (which arrives before a reply from the server that actually supported your initial version)? What if the attacker races to the server a packet with your 4-tuple, CIDs, and version but different contents, establishing a connection on the server for you, which you would not be able to decrypt? Etc.

I'd rather defer mitigations, if any are possible, to a later version of this draft (or a different draft).

[mikkelfj]

@igorlord There are definitely many more scenarios better handled in v2 or which are not practical to defend against at all without out of band knowledge such as signatures of some sort.

As to a VN with initial version, the draft already says:

A client MUST ignore a Version Negotiation packet that lists the client’s chosen version.

However "waiting a little" will give a valid packet a fighting chance against subversive attackers that wish to remain undetected.

[igorlord]

As to a VN with initial version, the draft already says:

A client MUST ignore a Version Negotiation packet that lists the client’s chosen version.

However "waiting a little" will give a valid packet a fighting chance against subversive attackers that wish to remain undetected.

That's right. I meant the attack claiming another version you support, not your original version. Given that browsers are likely to be supporting predictable version sets, picking a different one is not likely to be a challenge.

The other problem with just waiting is that the client is likely better off just failing over to TCP quickly to improve user experience.

[mikkelfj]

I won't necessarily argue against failover to TCP, but my working assumption is that QUIC is QUIC, even if the most likely implemention is QUIC/HTTP/HQ/H3 with support for TCP. Hence QUIC needs to be able to handle itself the best it can. Specific use cases may recommend fallbacks to TCP, but it won't work in general.

[igorlord]

Right, though HTTP with TCP failover is a very important use case. But even without TCP, there are other options, such as failover to another IP returned by DNS. Of course, if you have exhausted all options, waiting may be the best alternative left. I would delegate guidance on this to a draft akin to Happy Eyeballs for QUIC (Applicability draft?).