Re: QUIC Version Negotiation Extension

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Response also inline


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

> (reposting on proper topic)
>
> Some random observations reading through the document
>
> - Is the order relevant in the receiver version list?
>

Yes all lists of versions are ordered.

I might have missed it, but otherwise I think this should be mentioned
explicitly.



> - 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.



> - VERSION_NEGOTIATION_ERROR vs drop - I’m not sure it is a good idea to
> close the connection. The initials are public so it is possible to inject
> false versions. There are probably many other similar attacks we don’t
> bother with, but still …
>

Once we're this far in the handshake, we cannot recover from this error.
Dropping the packet will only make things worse.

It is that a given across all versions, without mentioning it explicitly
here? This links to the at most one roundtrip.



> - Downgrade - I’m a bit worried about state management and server
> redeployments. A server could reject a valid packet because an Initial was
> routed to a new server. (Reading further, I see this is addressed). This is
> probably a pragmatic solution, but it has an assumption about eventual
> global coordination. I suspect something could be done here with tokens or
> CID routing, but it is not trivial.
>

Sounds interesting. Do you have a concrete proposal?

Not off hand, but the idea is that the server encodes some context in a
token, that an upgraded server can understand such that it can either
impersonate the old version or reject the handshake. As for CID routing: (I
don’t recall if new initials with new version must carry same original CID,
and this might be version specific) - but if the a second Initial routes
the same place, similar to 0-RTT, you can limit the impact of server
deployment coordination to the one or the few servers affected by that CID.
If a version negotiation packet decides a new CID via the destination CID
field, a server farm is also able to route traffic to a segment with a
predictable version scope - for example by never updating some servers on
even hours and always redirect vneg to a subcluster that is not upgrading
and which therefor has a predictable version scope.




> - Security Considerations - perhaps it is worth noting the transport
> parameters need additional protection beyond the Initial packet protection?
> This follows from TLS, but if TLS is not being used, this can version
> negotiation even if other parts of the protocol version is not sensitive to
> this in that particular version.
>

draft-ietf-quic-transport section 7 requires transport parameters to be
authenticated.

but that is for QUIC v1. QUIC v3 might be for constrained devices that do
not use TLS and which do not migrate and which only has two non-hardcoded
transport parameters which are verified in 1-RTT in order to achieve a
light handshake. What would vneg do then? Notably such a version would
depend heavily on vneg because it really needs the one version that works
with its hardware accelerator, or whatever.

- Improve discussion of Previously Attempted Version. While the
> requirements are readable, the purpose of doing this check is less obvious.
> Presumably this deals with downgrade attacks, but more explanation would be
> appreciated.
>

The downgrade prevention section discusses the purpose of this field. What
details do you think we should add?

Generally QUIC does not argue why something is done, although sometimes
providing motivation (like you do here - downgrade prevention), but I’d
still like to better understand why this prevents a downgrade and why a
downgrade is such a bad thing, and how such an attack could happen, and why
comparing the previous version would prevent that from happening. Because
this is such a core element if the entire document.