validating Version Information on compatible negotiation

[kazu-yamamoto]

I'm reading editor's draft.

It says that both peers MUST parse Version Information. This is good.

However, a client MUST validate Version Information only on incompatible version negotiation ("acted on a Version Negotiation packet"). I think the same validation should be done on compatible version negotiation.

[DavidSchinazi]

Can you elaborate? What validation should the client do if it hasn't reacted to a VN packet?

[kazu-yamamoto]

I think that Chosen Version MUST be the same as the version in the Initial packet from the server.

[DavidSchinazi]

That doesn't quite work - sometimes you might use some packets of the original version (see #25 and #67). The security property we want is to ensure that after the handshake, the server's "Chosen Version" is the one used by the connection. That property is guaranteed by this text from the end of Section 6:

After the process of version negotiation in this document completes, the version in use for the connection is the version that the server sent in the Chosen Version field of its Version Information. That remains true even if other versions were used in the Version field of long headers at any point in the lifetime of the connection; endpoints MUST NOT change the version that they consider to be in use based on the Version field of long headers as that field could be forged by attackers.

[kazu-yamamoto]

@DavidSchinazi So, why does a server have to send back Version Information (which is not validated at all) for compatible negotiation?

[DavidSchinazi]

This exists to prevent an attacker from modifying the version: since the authenticity of version information is protected during the handshake, it guarantees that, once the handshake is complete, the client is using the version that the server chose.

[kazu-yamamoto]

Do you mean that a client should check if Chosen Version is the same as using version when handshake is complete?

[DavidSchinazi]

Yes, that's one way of implementing this