Need a NONCE in version negotiation packets

[igorlord]

Now that the client does not send a connection id in its version negotiation (see #119), client needs a public nonce in the packets. That prevents an off-path attacker guessing client source port and interfering with the client establishing connections with a given sever by spoofing version negotiation failure packets as if coming from that sever. That nonce should be returned by the sever in its version negotiation packets. Previously, client's connection id served such a purpose.

[ianswett]

The public reset has the same issue.

I'm not sure how serious an issue this is, since the attacker would also have to guess the server IP and port as well as the client port. In practice, this would be a very costly attack, because it only works during the handshake. Typically handshakes complete within a second, so to prevent a client from connecting to a single IP/port, you'd have to send thousands of packets a second, with no guarantee or acknowledgement of whether your attack was a success?

If we think it's a serious issue, we could also reconsider requiring a connection id from client to server on the initial flight.

[martinthomson]

Connection ID isn't the only field that contains entropy. As you say, IP and port do contain some entropy (though not much). Requiring proof that the server received a packet doesn't have to rely on those fields alone. That gets easier if you don't worry about version negotiation packets because you can put things in the TLS handshake (something that we might want to do anyway).

There really isn't anything very strong in the TLS ServerHello. The messages that follow have a very strong signal that the server received the ClientHello though.

[mirjak]

The packet number and a potential packet number echo from the server would help here as well.

[MikeBishop]

#361 purports to address this; please re-open or file a new issue if that's incorrect.