Re: Version negotiation: the bare minimum?

Christian Huitema <huitema@huitema.net> Tue, 16 March 2021 04:12 UTC

Return-Path: <huitema@huitema.net>
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 8CBC93A195A for <quic@ietfa.amsl.com>; Mon, 15 Mar 2021 21:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 Ai6LU6IRUAms for <quic@ietfa.amsl.com>; Mon, 15 Mar 2021 21:12:01 -0700 (PDT)
Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1778F3A1958 for <quic@ietf.org>; Mon, 15 Mar 2021 21:12:00 -0700 (PDT)
Received: from xse243.mail2web.com ([66.113.196.243] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lM13l-000jki-BE for quic@ietf.org; Tue, 16 Mar 2021 05:11:58 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4F00Gz4ht3zBTK for <quic@ietf.org>; Mon, 15 Mar 2021 21:11:55 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lM13j-0000En-HF for quic@ietf.org; Mon, 15 Mar 2021 21:11:55 -0700
Received: (qmail 22423 invoked from network); 16 Mar 2021 04:11:53 -0000
Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.58.43.146]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 16 Mar 2021 04:11:52 -0000
To: David Schinazi <dschinazi.ietf@gmail.com>, Watson Ladd <watsonbladd@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
References: <CACsn0cm-vWCZEeA+kh-BUF0M0ZhM_ev6R-9DYZgWQCA-byHofQ@mail.gmail.com> <CAPDSy+4QLJnE8njgsP33GQLnwtNH1v6ACbWTfOXhe00jXdwCbw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: Version negotiation: the bare minimum?
Message-ID: <6322e767-433c-7181-08ae-897c6625f3f2@huitema.net>
Date: Mon, 15 Mar 2021 21:11:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <CAPDSy+4QLJnE8njgsP33GQLnwtNH1v6ACbWTfOXhe00jXdwCbw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.243
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCOY9 9BPjO/baLGifW46qJujmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca+xnn3Ohf8XY5WZ+f/Kk3UxQ6V51u76v35b1wNe/MvdLom48E g3of4Y9DlgiJ0nAJ2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha6vH0PZUsqM6/e5MEyOxH5FU 2brG5IQTBu9ggerGcWrGDRojSVizNl0ce/s7u0P9b9Tml6eOMCV9kYYwkPx6ZsXvIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfDnsQvS3LzFXpoY+Q/s/aUNUoFIvD3sIcP1fhJPM6B/8kJPH OaKNsK6YcQ45ubpDm7xZ1H6mbk6k6aQAB9HEpyiJ+dym1L8cD17Js0v4cp1Mp0PGVMzdj/HuGqk6 o+wTLTcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/w5l06JPmG0gDi6cyWL_LH-wGTk0>
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 04:12:03 -0000

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