Re: Version negotiation: the bare minimum?

Christian Huitema <huitema@huitema.net> Tue, 13 April 2021 07:06 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 3BCE53A0E0E for <quic@ietfa.amsl.com>; Tue, 13 Apr 2021 00:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 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, URIBL_BLOCKED=0.001] 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 uxzyZhv7nf_E for <quic@ietfa.amsl.com>; Tue, 13 Apr 2021 00:06:25 -0700 (PDT)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 B685B3A0E0B for <quic@ietf.org>; Tue, 13 Apr 2021 00:06:25 -0700 (PDT)
Received: from xse374.mail2web.com ([66.113.197.120] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1lWD7u-000qVD-CX for quic@ietf.org; Tue, 13 Apr 2021 09:06:24 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4FKGqJ5yW9z9yb for <quic@ietf.org>; Tue, 13 Apr 2021 00:06:20 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.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 1lWD7s-0007yU-MN for quic@ietf.org; Tue, 13 Apr 2021 00:06:20 -0700
Received: (qmail 28360 invoked from network); 13 Apr 2021 07:06:20 -0000
Received: from unknown (HELO [192.168.1.52]) (Authenticated-user:_huitema@huitema.net@[88.141.82.217]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 13 Apr 2021 07:06:17 -0000
Subject: Re: Version negotiation: the bare minimum?
To: Watson Ladd <watsonbladd@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
References: <CACsn0cm-vWCZEeA+kh-BUF0M0ZhM_ev6R-9DYZgWQCA-byHofQ@mail.gmail.com> <CAPDSy+4QLJnE8njgsP33GQLnwtNH1v6ACbWTfOXhe00jXdwCbw@mail.gmail.com> <6322e767-433c-7181-08ae-897c6625f3f2@huitema.net> <CAPDSy+6dH9iVeRxQeAkNqCQKLSP510L3Nm+ZwRYsmQKGaMVNGg@mail.gmail.com> <CALGR9oZ+nL7PgUYwbeRS25HbHQfEAdtVuMySPZnf3f8J=pyC0A@mail.gmail.com> <CACsn0c=MTyb3SWBN9-k-ZfiB3YE=WCYSRB7sPEw=4LJ9STPaTw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <fbcc7edf-cbd1-be18-bf95-8dcfdbc2fab2@huitema.net>
Date: Tue, 13 Apr 2021 00:06:14 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CACsn0c=MTyb3SWBN9-k-ZfiB3YE=WCYSRB7sPEw=4LJ9STPaTw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: 66.113.197.120
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.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/EwzSHE5FGYwwjsNRPCNT/ T2r/RIN1HvhpmU8Gp2XmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca+xnn3Ohf8XY5WZ+f/Kk3UxQ6V51u76v35b1wNe/MvdKAGdwU TZKlze5ERymXAD3v2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fugQgzjcNVPTK7tBwQaGKcWpU J0CVkysm1h7hi1Gj9VWZDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfJVqDNUAq7dvuLWMNzIPZTRUoFIvD3sIcP1fhJPM6B/8VxL3 4Af636p1FllhR3ctp7dl9OIB11Y8GHx5spPIC/eJ+dym1L8cD17Js0v4cp1Mte5lU3HSLmxLZZ6n BCuoRjcKVNeVJ9BXyu9+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/Xzt7AwG-qroAtWgNtxtdhgI9nBM>
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, 13 Apr 2021 07:06:30 -0000

On 4/12/2021 10:11 PM, Watson Ladd wrote:
> On Mon, Apr 12, 2021 at 12:44 PM Lucas Pardue
> <lucaspardue.24.7@gmail.com> wrote:
>> Hi Watson and Christian,
>>
>> Thanks for your input on the topic of QUIC Version Negotiation. The thread has fizzled out a bit. The QUIC Version Negotiation interim meeting is next week (Wednesday April 20, 21:00 UTC), it would be great if you could add some further concrete ideas to the discussion. In particular, if you're describing an alternative to what the VN draft has today, there is value in us hearing it out because it might help the QUIC WG make progress in this area.
> I would be happy to attend.

I will try to attend too. If I can find the invite and link...


>
>> Kind regards
>> Lucas
>> QUIC WG Co-chair
>>
>> On Wed, Mar 17, 2021 at 12:42 AM David Schinazi <dschinazi.ietf@gmail.com> wrote:
>>> Hi Christian,
>>>
>>> It seems to me that you're describing what's in the VN draft today.
>>> What am I missing?
>>>
>>> David
>>>
>>> On Mon, Mar 15, 2021 at 9:11 PM Christian Huitema <huitema@huitema.net> wrote:
>>>> 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
>>>>>>
>>>>>>
>