Why is the original version not authenticated?

Question

Why is the original version not authenticated?

DavidSchinazi opened this issue 2 years ago · comments

David Schinazi commented 2 years ago

Draft currently states:

Note that the version of the first Initial and the subsequent Retry are not authenticated by transport parameters.

Is this true? The client sends this as its Chosen Version right?

Martin Duke · Answer 1 · Sat May 21 2022 04:16:49 GMT+0800 (China Standard Time)

I don't think so?

If the client receives a v1 Retry and then chooses to connect via v2 for some reason, that won't break the transcript.

David Schinazi · Answer 2 · Sat May 21 2022 05:54:14 GMT+0800 (China Standard Time)

The "for some reason" doesn't make sense to me here. If the client follows the normative language in this document and in QUIC VN, it won't magically switch to v2 after receiving a v1 retry - it will instead send a second v1 initial which will contain the retry token and also chosen_version=v1, other_versions=(v1,v2).

Also, while we're at it, what is the "subsequent Retry" here? Can you write up a packet diagram to explain the flow you have in mind? (on this issue not in the draft)

Martin Duke · Answer 3 · Sat May 21 2022 07:09:11 GMT+0800 (China Standard Time)

Ah, I'd forgotten that in 4.1 we validate the version in the Retry token. I'll delete the sentence.