Re: QUIC Version Negotiation Extension

Mikkel Fahnøe Jørgensen <> Mon, 04 November 2019 22:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C57BF120043 for <>; Mon, 4 Nov 2019 14:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2k3oltW0sxcB for <>; Mon, 4 Nov 2019 14:35:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8010912009C for <>; Mon, 4 Nov 2019 14:35:24 -0800 (PST)
Received: by with SMTP id d23so11793996edr.5 for <>; Mon, 04 Nov 2019 14:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=p2ieLO38DUkHjnoyxH2AyanDZCwUDmB/dFqpo0Pm/KU=; b=Ik9NkOuQx2yd1MiexHdEEEQ5xr/9cYTgx1aZeV4R77Y/7ilgJYcBKZYk3XDEopIIV3 UoIAwDTWvwpIlYHVXZ6ulIpFF5OzSLFUvUhVyTzZDqlmFOrX/TtINMdg49DFlZinW61e 0HU01KoncTiTZM8ln7Nl1iDjwS6bEtkSaj8PFN+VAh2zetb8HvQRKN0t183uWP/HAlp1 ymW+tBiWukeK/Zopx3ghGE1p/kihkkPJiEdiq7Hhg0GrDxw91rCiEfMMiKZnVP5WPOSw 4SAfpODP5IJW1XcWSh3y+S8v9G158TT9uKTYGuxJqjiTrr3DwGagR1cAocWv+z7Tiu7R mQ2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=p2ieLO38DUkHjnoyxH2AyanDZCwUDmB/dFqpo0Pm/KU=; b=gJlyAMCQ31gAYBGGCNszPlPXPO9eZNDrqBDVlEwdl3vhLxHwqfAZ0NKhGIrJ/zLPOq wFJG/g7CBvBKyusjSOf+DnNQGqs/Nhv0EXof4kuICFPbvt8FYQrYsqorJYa5JHscIjO6 Dioh85lz4e3hdToCO8ugpDyRLdlFDEqqe5G46H2Y1Y525OdbLBm7HXtxVj5wsMzQfbR7 ++/ZtBl50zbIpHh9yF87fjVYinqpzWLjF09kBTdYUnL5qTmK8UNXCI/E3SqWEnTx0qDo yAdVZrvwe0zbzpbH1qq7Ie/RFMhcONiWr9KL4l7rMpZrLchKXINXMk6J62u2p5QB8PyJ +qxQ==
X-Gm-Message-State: APjAAAXlLq+pe8V2ZbTfpaGdULAOKel3FgzrFSXKbvgU86GVmouIZLC8 12SdEc5XBQWrChyymYhMfrTM8M1KuuVuYojMiJM=
X-Google-Smtp-Source: APXvYqwvCWUF+PTWzYSujy1BsyJa9tMQuBFC7L95siEjAYLcN8IqyFQOaNhIkx4nKQcLccw7XeaPulrhUMFEwbomh4g=
X-Received: by 2002:a17:906:1da1:: with SMTP id u1mr27081213ejh.275.1572906923013; Mon, 04 Nov 2019 14:35:23 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 4 Nov 2019 23:35:22 +0100
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Mon, 4 Nov 2019 23:35:22 +0100
Message-ID: <>
Subject: Re: QUIC Version Negotiation Extension
To: David Schinazi <>
Cc: QUIC <>
Content-Type: multipart/alternative; boundary="000000000000693cab05968cee05"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 22:35:29 -0000

Response also inline

On Mon, Nov 4, 2019 at 1:47 PM Mikkel Fahnøe Jørgensen <>;

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

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

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.