Client validation #49
Conversation
In light of discussion in slack, the problem here is that the validation is based on the *negotiated* version. Validation needs to be based on the client's *selected* version. I've also moved text about validating lack of support for the original version to the incompatible VN section, alongside a reminder to validate connection IDs. Security does depend on this, but the client ignores these bad VN packets. That provides more effective defense against attack than what was proposed.
| @@ -28,6 +28,9 @@ author: | |||
| organization: Mozilla | |||
| email: ekr@rtfm.com | |||
|
|
|||
| normative: | |||
There was a problem hiding this comment.
Out of curiosity, does a syntax like {{Section 6 of !RFC8999}} not work?
There was a problem hiding this comment.
It didn't when I last touched that code.
| `VERSION_NEGOTIATION_ERROR`. This connection closure prevents an attacker from | ||
| being able to use forged Version Negotiation packets to force a version | ||
| downgrade. | ||
| The client MUST validate the server `Other Versions` field by confirming that it |
There was a problem hiding this comment.
This requirement only applies to clients that have reacted to a VN packet right? What validation MUST a client do if this connection didn't involve a VN packet? (in other words, why drop the "If a client has reacted to a Version Negotiation packet," part?)
There was a problem hiding this comment.
Why shouldn't the client do the same validation during compatible version negotiation?
There was a problem hiding this comment.
There are ways in which the two are different, so I think David is right here.
Let's say that there are two groups of versions, the versions in each group compatible with each other, but incompatible with the versions in the other group. The client prefers a version in the first group, but the client also knows that the versions in the first group are not widely implemented. As the client doesn't like the added latency of version negotiation, it chooses the second group, which contains a version that is totally OK. However, if it gets a Version Negotiation packet as a result, it will happily switch to the first group.
So yeah, let's go with the "if VN" condition.
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
In light of discussion in slack, the problem here is that the validation
is based on the negotiated version. Validation needs to be based on
the client's selected version.
I've also moved text about validating lack of support for the original
version to the incompatible VN section, alongside a reminder to validate
connection IDs. Security does depend on this, but the client ignores
these bad VN packets. That provides more effective defense against
attack than what was here originally.