Re: QUIC Version Negotiation Extension

[David Schinazi <[e-mail]>]

On Mon, Nov 4, 2019 at 3:07 PM Mikkel Fahnøe Jørgensen <[e-mail]>
wrote:

> Yes all lists of versions are ordered.
>>
>> I might have missed it, but otherwise I think this should be mentioned
>> explicitly.
>>
> Isn't it mentioned in the definitions of these fields?
>
> Yes, rereading that passage, it does mention order.
>
>
>>> - It is tempting to just hash the received version list, but that
>>> requires agreeing on an algorithm, unless the algorithm is stated to be
>>> specific to that version, which is complicated.
>>>
>>
>> Which list are you referring to? For all the ones in the draft, the peer
>> needs access to all the elements so I don't think a hash would help.
>>
>> I am referring the received list. The client receives the list. The
>> server (modulo redeployment/routing) knows its own list and does not need
>> to read it, it just needs proof that the response matches what it initially
>> sent. This could be done with a hash. (If I understand correctly). But
>> maybe not because the list is filtered by clients input so that would be
>> many hashes to track.
>>
> I don't know what the received list is, there's nothing with that name in
> the draft.
>
>
> Received Negotiation Version Count + following element
>
>
Those are received by the server. And the server needs to access all the
the versions there in case it randomizes the reserved versions or has
different versions on different servers in the fleet.

> The current design of connection IDs does not guarantee consistent routing
> on client-generated server connection IDs, so I don't think we can rely on
> it.
>
> So this is where I’m not 100% on how it works, but VNEG packet does, at
> least in principle, allow for a return destination CID, so the next Initial
> packet can use that destination instead of a random original CID. And
> likewise, if the response is not via VNEG, the servers initial can the same
> (on known versions).
>
Version Negotiation packets MUST use the same CIDs as the client's initial.

> I think QUICv3 should also provide this property, otherwise it'll be
> likely to be unsafe. If a future version doesn't have authenticated
> transport parameters then we'll have to create a separate downgrade
> prevention mechanism. But we can cross that bridge when we get there.
>
> Sure, but perhaps mention in Security Considerations, that the design
> depends on this, if it is not considered blatantly obvious.
>
I'll admit I thought this was obvious, since it relies on transport
parameters. We'll take a PR though.

> It sounds like we could be clearer. Would you be able to send us a PR?
>
> I’ll consider, but I’m stretched a bit thin as it is.
>