Repeating Version Negotiation

[martinthomson]

Servers shouldn't need to send more than one version negotiation packet, they only resend so that they are stateless and to deal with packet loss on the return path.

Clients should ignore version negotiation packets if they already have received packets from the server.

This requirement on the client could be used for denial of service in the case where the legitimate server needs to use version negotiation. If an attacker can race a legitimate looking ServerHello at the client (which isn't impossible), then the client will ignore the real server's attempt at version negotiation. This is hard for an off-path attacker due to the need to echo certain parts of the client initial packet. (I'd say connection ID is enough, but that might run afoul of #119.)

[martinthomson]

The denial of service exposure is limited to an attacker successfully racing their ServerHello with the legitimate response from the real server. With #361, an attacker doesn't need to see the entropy in the QUIC header to construct this message, all it has to know is that the client is going to be trying to handshake on a given 5-tuple.

The fact that the remainder of the packet will be unusable (an off-path attacker won't be able to construct a valid set of handshake traffic keys) doesn't mean that the client will be any happier. The only defense against that is to insist that the client operate multiple parallel handshakes. That's probably too much effort for an attack with such narrow applicability.

If the attacker is on-path, they win, of course.

Historically, we've let denial of service attacks on the handshake to succeed, it's just too easy for an attacker to mess with things at that stage. That might be the right answer here too.

[martinthomson]

Closed in #474.