Re: QUIC Version Negotiation Extension

[David Schinazi <[e-mail]>]

Thanks for reading Mikkel! Responses 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.


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


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


> - Checking that a transport parameter field is the same as the long header
> version seems redundant - why have those fields? Is it because the Initial
> header fields are not sufficiently protected via TLS magic (or similar)?
>

Yes, this makes sure an attacker cannot spoof the version field in initial
packets.


> - We generally use varint, but why have varints mixed with 32-bit version
> lists? I suggest making the list length 32-bit for easier processing.
>

QUICv1 uses varints pretty much everywhere, we're sticking to that design
here.


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


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


> - Greasing 0x?a?a?a?a - I’m not really sure about the point of this.
> Especially if we get salted versions in separate proposal.
>

We follow the QUIC reserved version design here.


> - It is not immediately obvious if version negotiation can go on and on,
> or if it settles after at most one roundtrip one way or the other. This
> might depend on the client QUIC version, but that is a fuzzy term in this
> context.
>

It can only happen once, though it might be a good idea to make that
clearer.


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

Mikkel
>
>
> On 4 November 2019 at 21.30.10, David Schinazi ([e-mail])
> wrote:
>
> Hi everyone,
>
> From the recent discussion on multiple PRs, it appears that there might be
> a need for downgrade-safe QUIC version negotiation, earlier than we
> expected.
>
> EKR and I updated our extension to hopefully suit these needs:
> https://tools.ietf.org/html/draft-schinazi-quic-version-negotiation-02
>
> Comments welcome here or on the GitHub (link in draft).
>
> Thanks,
> David
>
>