Re: Version negotiation: the bare minimum?

David Schinazi <> Tue, 16 March 2021 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 831E93A13F6 for <>; Mon, 15 Mar 2021 17:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] 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 fH2kN2nHOazD for <>; Mon, 15 Mar 2021 17:19:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 304BA3A13F5 for <>; Mon, 15 Mar 2021 17:19:06 -0700 (PDT)
Received: by with SMTP id e26so7631567pfd.9 for <>; Mon, 15 Mar 2021 17:19:06 -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=PpdIv69yzEdDtfjcK2Km+vFm7EGAMXb1mn8xA1bSMQY=; b=T0kKMMMjyitMF/l0dE4s+fbM9J9cW20ASKTuDGTNCzjwu+MQmGItkEaeDKRaDEr51h DCLAUEI5eeRou65jRmMIimLTuCeyaXacp3LQJKigyBeHCDhE7yuWUP/EwkrcREvJr6vr dbgHdtweJ3dsV32ouGv46BwCrMBl0QZAH2F5Vl2YSce7TElDM0Buo7C43l+vyiTEPFwM vEPJkh1lqGTf9CnjGbrL+gG8FnfiItKl278QwKzEEevXSiuZnBGcfIEUZPzk/Z5xTHs5 L/XIwExyGw93VSG3o8R5Nxmc5UKZXbSTgQycVOZtwhNo+a5nd7mYP5ilGa43Kh3kk15h 1cFw==
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=PpdIv69yzEdDtfjcK2Km+vFm7EGAMXb1mn8xA1bSMQY=; b=PgGtHbYQkZSdmjmniArnrdH5jwapNOXYeGe8NU3+XhmKpqGqWOapiifRIHcsQuT/qz xHH//+J+nA2zKqvqbQO11UOUmZ0Bdducr+o6Ze/T5/c/g9e4Cq5N6kNAdIWTrQ+Kr1Xx qV3LE0LzGzXAZj2fJBLd2I9wnWSe7YAh+CErll52ZDRjCayTthDr447bFIIxh5pmAgV2 rUrWzFGVvheE12jG+XxIg1e/Jv/QvMzP5kK2m1E8oBjh7zGYGwcy8SSR/IrV4QHMmnrb nUb1GyZnuxLgwtrVKs3teGA46+Y5NcrAIWlfXPR7fU1DRXIWNSNir5/lF9JS78wxGoY7 /rVg==
X-Gm-Message-State: AOAM533MCpCEXJYjICLOSKVfRS0AoCJQ4/XkUnA8Bb3THZIZrhWWs12Y vuCICqLdv+6gQEWm/xlaFLb0tJERByLeYkmljBs=
X-Google-Smtp-Source: ABdhPJx7Ic9KkPxn0xC5Af2Oe0NuledZg8keE4vAOa48Yc87A52w23XMnNP+jpTlteQjmlvGrGyu6u4hpNA3gVrfg5M=
X-Received: by 2002:a62:528e:0:b029:1f5:c5ee:a487 with SMTP id g136-20020a62528e0000b02901f5c5eea487mr26245404pfb.7.1615853944503; Mon, 15 Mar 2021 17:19:04 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Schinazi <>
Date: Mon, 15 Mar 2021 17:18:53 -0700
Message-ID: <>
Subject: Re: Version negotiation: the bare minimum?
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary="0000000000005eff6605bd9c50b4"
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: Tue, 16 Mar 2021 00:19:08 -0000

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?


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