Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)

Kazuho Oku <> Wed, 21 April 2021 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14DCE3A1597 for <>; Tue, 20 Apr 2021 23:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mdsaUuMhwNM4 for <>; Tue, 20 Apr 2021 23:40:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4927F3A1595 for <>; Tue, 20 Apr 2021 23:40:03 -0700 (PDT)
Received: by with SMTP id bx20so46829111edb.12 for <>; Tue, 20 Apr 2021 23:40:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EaEZAQXCrDnGNEPO8X28XPagb6aaGkkWMaGvEDzmr9g=; b=fwzGO/19c6ZWp1/RataSYVieaqGmBybXH5gqjdney7M2ncGxff1ZZyntV/QNdmQhct YB/F6PwCbr7vmFM+OiLMB/Yff6utcq8+uD7d8l3B+ClfZXjzYU230aQXvHk+bt1y7pxT ifegKzwodQ84i8sQF8SmvsmNsfLY0/iBnk9XTFceEmLTXWAr2mhNXmYG6cAOOoUlwkWM 6igT/flMxQL2/fAmxqD/yCsnGDJ3D6hUVhfplR67vr2TAVCoWBTzquwlE0VDQFjvNkB3 yqcAmhyp1wX7iBllcrZ1xz58DEvHUifnWQ5h/0OvJntj+71+fUwaZRLIYtAnsGEylsZj +JaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EaEZAQXCrDnGNEPO8X28XPagb6aaGkkWMaGvEDzmr9g=; b=Ve1XomB/3vEtlw/m/i7xsel2PkV3Z44iy9SU6Sh7ZQGcyBo7uHNCVfOHct+qC1aH6C 2ZFWz1gMc9+4HpmK575OIMGFXWQX0hUCcdcm4X3MEvg4RzLK6Ojyq45kx6qIOlvi+lBv N3tWXwLruXp/Bp8MISwJ3r6TLSSucX4kKKyI1AQVzd1j4BbPGpSkCL5j+6J1Ijjmp2SZ ULgavgEaMq01f3SDm04clzSNqLhjjiIiJXwKmM4sfAneRCl1jg6vUHbCSp+tatau3F49 +yWVFI9VeeSF3Pl9vr1Bp8lWX1VtVPQtQZm9iTCMderSaXOAEdZ4+JXBi7oedrRE7rP6 0pRA==
X-Gm-Message-State: AOAM533X5jNEih9PiIL28/5hBJsp9wAUBAUyZXfFPvVjKTTl9GH6bsoG L8rq+pdorxpaSFeCLZ+zOCgEjNLJizMp7/eLKdg=
X-Google-Smtp-Source: ABdhPJyy0FjsyK3OfSdzb9//A2PZJ44d91zsLNlrnWm0OxaWWrH5pSFiT42snS/xuRnPYao6vJa78kCqhWjiStvpHgA=
X-Received: by 2002:aa7:cf16:: with SMTP id a22mr16908124edy.23.1618987201116; Tue, 20 Apr 2021 23:40:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Kazuho Oku <>
Date: Wed, 21 Apr 2021 15:39:50 +0900
Message-ID: <>
Subject: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)
To: Christian Huitema <>
Cc: David Schinazi <>, Watson Ladd <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000004bb0f05c075d5a2"
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: Wed, 21 Apr 2021 06:40:08 -0000

Please correct me if I'm wrong, but it seems to me that people are using
"compatible version" as a term to describe packets carrying first-flight
initial data (e.g., ClientHello) using QUIC version X to which servers
might respond with something other than Version Negotiation packets _nor_
QUIC version X packets.

IIUC, the intention is to allow endpoints start the handshake using QUIC v1
but end up with using something other than QUIC v1, without incurring the
cost of one extra round-trip due to Version Negotiation packet being sent
by the server.

Based on this understanding, I have one question. Do we need such a feature?

QUIC v1 already has Transport Parameters that can be used for negotiating
how 0-RTT and short header packets would be used. By using Transport
Parameters, we can define extensions that add, modify, or remove any
feature wrt how application data would be exchanged.

The idea of having a mechanism for selecting a QUIC version between
"compatible versions" sounds to me like just creating another way of
negotiating features using TLS messages as the conveyor. Hence the question.

2021年3月16日(火) 13:12 Christian Huitema <>:

> I have been considering pretty much the same design as Watson. In the
> slide deck that you presented, this would be the "compatible" option.
> The client would select  version X in the QUIC header of the Initial
> packet, and format one or several TP stating:
> 1) Version in the QUIC header: X
> 2) Supported compatible versions: Y, Z, T, and maybe Grease. These must
> be "compatible" versions.
> The server will:
> 1) verify that the version in the QUIC header is indeed X. If it is not,
> close the connection with an error.
> 2) pick one of X, Y, Z or T as the selected version, say Y.
> (Questionable whether the version in the QUIC header should be set to X
> or Y.)
> 3) Set the TP stating something like "you proposed X and I selected Y"
> 4) Very optionally, mention in a TP that "this server also supports
> versions V, W." These might be "incompatible" versions.
> If none of X, Y, Z, T are supported, the server replies with a VN.
> On receiving the server TP, the client verifies that the server saw the
> intended version X, and chose one of the supported version. The client
> might remember additional version V and W for next time, but that's
> extra complexity.
> -- Christian Huitema
> On 3/15/2021 5:18 PM, David Schinazi wrote:
> > Hi Watson,
> >
> > Could you elaborate on your proposal? In particular:
> > How does the client transmit its supported versions?
> > What does "compatible" mean?
> > What does "the server selects" mean?
> > What does "the server proceeds" mean?
> >
> > Thanks,
> > David
> >
> > On Wed, Mar 10, 2021 at 1:55 PM Watson Ladd <>
> wrote:
> >
> >> Dear WG,
> >>
> >> I'd like to proffer the world's simplest version negotiation scheme,
> >> based on comments heard during the meeting today from a number of
> >> people.
> >>
> >> The following weak assumptions are made: the client has a set of
> >> versions. The server has a partial ordering on versions: this means
> >> that versions are not necessarily preferred over each other (consider
> >> experiments where we will do what the client offers first), but the
> >> relation is transitive. Then the server selection is a function of the
> >> client offered version and supported set.
> >>
> >> The client transmits its supported versions and a proffered hello
> >> version in the first packet. The server selects. If that selection is
> >> incompatible they try again with the new selected version transmitted
> >> in VN. If it is compatible, the server selects and proceeds.
> >>
> >> The constraint on the handshake is that the supported versions and
> >> offered version and server selection are incorporated on the handshake
> >> in such a way that a mismatch triggers failure, and no two different
> >> versions can derive the same keys. If we assume that e.g. SHA256 is
> >> unbroken this is easy to get.
> >>
> >> This only permits a downgrade to a version the server was willing to
> >> prefer.
> >>
> >> Sincerely,
> >> Watson Ladd
> >>
> >>

Kazuho Oku