IETF Logo Mail Archive

Re: Version negotiation: the bare minimum?

David Schinazi <dschinazi.ietf@gmail.com> Tue, 16 March 2021 00:19 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831E93A13F6 for <quic@ietfa.amsl.com>; Mon, 15 Mar 2021 17:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH2kN2nHOazD for <quic@ietfa.amsl.com>; Mon, 15 Mar 2021 17:19:06 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304BA3A13F5 for <quic@ietf.org>; Mon, 15 Mar 2021 17:19:06 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id e26so7631567pfd.9 for <quic@ietf.org>; Mon, 15 Mar 2021 17:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CACsn0cm-vWCZEeA+kh-BUF0M0ZhM_ev6R-9DYZgWQCA-byHofQ@mail.gmail.com>
In-Reply-To: <CACsn0cm-vWCZEeA+kh-BUF0M0ZhM_ev6R-9DYZgWQCA-byHofQ@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 15 Mar 2021 17:18:53 -0700
Message-ID: <CAPDSy+4QLJnE8njgsP33GQLnwtNH1v6ACbWTfOXhe00jXdwCbw@mail.gmail.com>
Subject: Re: Version negotiation: the bare minimum?
To: Watson Ladd <watsonbladd@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005eff6605bd9c50b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/soljrNY4f5AISXuK8mRfPq46zCw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=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?

Thanks,
David

On Wed, Mar 10, 2021 at 1:55 PM Watson Ladd <watsonbladd@gmail.com> 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
>
>

v2.23.0 | Report a Bug | By Email