Retry and compatible upgrade
martinthomson opened this issue · comments
It is necessary to specify how retry works when a compatible upgrade is used.
The easiest way to specify this is to say that Retry can be sent in version 1, but the validation is performed as though a version 2 retry was sent. That's what I've seen implemented thus far.
Here's the relevant text in your PR (numbers mine)
(1) A server SHOULD produce a Retry packet in the same version as the Initial packet
that the Retry packet responds to. (2) Validation of the Retry exchange uses the
logic of the final negotiated version, treating the Retry as if it were sent in
that version. (3) This means that the version used for Retry is not authenticated,
only that it occurred and the connection ID that was used.
(1) I made it a MUST in the recent merge, to make it a bit easier for clients.
(2) I'm not really sure what this means in the context of v1/v2 -- the logic is identical in both cases. Maybe this is something for the v1->vn text (pending) in the VN doc? But yeah, anything in the client hello, including the retry TPs, are processed syntactically as v1 but the content is used for v2 purposes. Do I understand the takeaway correctly?
(3) This is a fair point to make, I guess: the Retry logic only ever measured that the CIDs matched. But, meh? The client changing the version between connection attempts would be strange, but legal and not obviously dangerous. If you think this sentence is valuable, I can add it.
- Fine.
- Yeah, this was just a wording choice of mine. I do think that the validation is an important point to be clear on, lest people decide to skip it. I don't think that this can be part of the VN document at least as it stands as the Retry mechanism is version-specific and so any handling of it also needs to be.
- This is really just noting the limitations of the validation. I don't think that it has security consequences, particularly if the client enforces the requirement that Retry use the original version (which, presumably they are permitted to... by dropping the packet).
quicwg/version-negotiation#78 is going to introduce some considerations specific to v1. Nevertheless, I'm happy to write something down here.