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

Kazuho Oku <kazuhooku@gmail.com> Wed, 21 April 2021 20:19 UTC

Return-Path: <kazuhooku@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 656613A3534 for <quic@ietfa.amsl.com>; Wed, 21 Apr 2021 13:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 toA03VFp5CCi for <quic@ietfa.amsl.com>; Wed, 21 Apr 2021 13:19:38 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 2CB8D3A352D for <quic@ietf.org>; Wed, 21 Apr 2021 13:19:38 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id i3so25126711edt.1 for <quic@ietf.org>; Wed, 21 Apr 2021 13:19:37 -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=jXEJn6anD3gKz5EpM/TkG3inHA0Z/DbEnCqctJYTbmk=; b=BWi+CkQxoo06ngV7j4Fjc3OesS1XoVXcVoiC0kRQMutKzulGfDrs6FQ+OaipzkSnZG +UIjME8l3PYMbtXSvP9AiErxNxpQHeHKFhizoKW6BbBPnEm+STbJBkaQSOQPciOTLjx5 CQ4x2Qctyhi9SYxyNZeuNsST9jiGnCzSIsIk99DrxGuEs2PWEFAbK+hNXnEcPHwKhbdk JwrN4mhfM8FVIzNEM2G49QiDoI4WcfXpNiWGOQlAW5uNWn7LRZ3XpJ6C3d9x3uhiX5G+ ZNFXbDVbOZcDRRTBqvgI3JnbTxeWU72hn4b6Rol2hRHY2KuHxOx+m6vvIl6TPa1X0ah8 HPYQ==
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=jXEJn6anD3gKz5EpM/TkG3inHA0Z/DbEnCqctJYTbmk=; b=cJecOVW6UG8W/VHBYxHrN5eQlIPW1OXmOA9HsBpJOK+uw2hZd5poglKRJ35S2tFJLl 1ezgimsDZshuh8NXLiseX50LAq81rysM1w80Ze3+xcjAHBOFCaCdmVkFyObvAYi+svy6 ZU/qhJiZ57lQ/+HmVRJCEBWQT6IyY7BnVJ5/LlnTSVesOlCu/c2wSl6AZIRc5/QuH9A5 V+LATgsa7cUc/rSl+xTfyoahoV0UvxN75bBb9y5n7+BQGT7F9AxU+bhKHn6CWYpVwtvb waX4q0Dd5C/S255pTe994EQquNSd7jCZQnExOzGa3qpG6CW5R94cedvPnhd+n6Ixnb30 d0VQ==
X-Gm-Message-State: AOAM530j0tg2wR9R0xPeg6DbW73Gl7yd5t9D2WFzN/0es+qBBvCboIEM kFSxfvkAJZY7dfVUGMmeBRl7eeDOpv36snx+o28=
X-Google-Smtp-Source: ABdhPJzY5no1b5MzS6KWJkmu/IVfcW1o3jEzNmB/NVhwNpM69MN9Lbz2qW2NNXXARQ1rdcqtiyqxfg+W1MgGpP0BmSI=
X-Received: by 2002:aa7:c9c9:: with SMTP id i9mr26358383edt.17.1619036375122; Wed, 21 Apr 2021 13:19:35 -0700 (PDT)
MIME-Version: 1.0
References: <CACsn0cm-vWCZEeA+kh-BUF0M0ZhM_ev6R-9DYZgWQCA-byHofQ@mail.gmail.com> <CAPDSy+4QLJnE8njgsP33GQLnwtNH1v6ACbWTfOXhe00jXdwCbw@mail.gmail.com> <6322e767-433c-7181-08ae-897c6625f3f2@huitema.net> <CANatvzzgKtN+jW_yqhfzQwZBeiFLDY-+2DQ3BuWACX7LkeSxqA@mail.gmail.com> <CAPDSy+7DNyKJTs1BjKMszJU0PgBT5v8PO9g49a59oW3Vh0eusA@mail.gmail.com>
In-Reply-To: <CAPDSy+7DNyKJTs1BjKMszJU0PgBT5v8PO9g49a59oW3Vh0eusA@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 22 Apr 2021 05:19:23 +0900
Message-ID: <CANatvzz9tJ8tjJRVhjesAQjX51wV_686uTH526w5thvbem8+qw@mail.gmail.com>
Subject: Re: Do we need compatible version negotiation at all? (Re: Version negotiation: the bare minimum?)
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, Watson Ladd <watsonbladd@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004870a05c0814864"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KszoacTJE_9EAhBT4AhwaxiT-UE>
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: Wed, 21 Apr 2021 20:19:41 -0000

Hi, David, Christian,

Thank you for your comments.

2021年4月21日(水) 23:48 David Schinazi <dschinazi.ietf@gmail.com>:

> Hi Kazuho,
>
> First, to confirm: your characterization of compatible VN matches my
> understanding.
>
> Then, on the topic of what we need, let's start with basics. Your point
> that QUICv1 has extension points is true,
> but we've designed QUIC as a versioned protocol to allow innovation
> outside of the confines of QUICv1. We
> could in theory say that the QUIC version field is ossified and no other
> versions are allowed for perpetuity,
> but I think that this would be a loss for our ecosystem. If we assume that
> there is value in having other versions
> of QUIC, then there is a need for version negotiation. This doesn't apply
> to HTTP/3 or other application protocols
> that negotiate their QUIC version out of band (e.g. via Alt-Svc), but we
> built QUIC in such a way to specifically
> enable non-HTTP application protocols. Now, given that we want version
> negotiation, we'll need at least incompatible
> version negotiation, as that is the one that supports all potential
> versions. If we decide to build incompatible version
> negotiation, we need to prevent downgrade attacks - attackers should not
> be able to modify the version field on
> long headers, and should not be able to inject or modify version
> negotiation packets. To solve this, we need to
> authenticate these versions in the TLS transcript, which means adding a
> new transport parameter. At a minimum,
> this transport parameter needs to include the versions being sent in long
> headers, and needs some form of what
> was sent in a version negotiation packet.
>
> To summarize that wall of text, if we don't want to ossify on QUICv1, we
> need a new transport parameter with
> some version information.
>

I think I agree to what David has written here, regarding the importance of
incompatible version negotiation.

As David points out, having in QUIC v1 downgrade prevention for
incompatible versions is a MUST, for somebody deploying a QUIC version that
is incompatible with QUIC v1 (e.g., a variant that does not use TLS as the
handshake mechanism), considering that such version is more preferable to
be used than v1 when both can be used.


> Now, to answer your question about compatible version negotiation: it does
> mean adding one more field in the
> client-to-server transport parameter so the client can list its compatible
> version. In terms of wire encoding, that's
> the only change. The only complexity in compatible version negotiation is
> in defining the concepts.
>
> My personal opinion is that we should tackle this minor complexity in
> order to make QUIC more robust. Having a
> version negotiation mechanism that doesn't cost a round trip will help
> encourage innovators to use new versions
> of QUIC as opposed to shoehorning everything into extensions to QUICv1. My
> intuition is that this feature will
> impact the long term success of QUIC, and is therefore worth the minor
> complexity.
>

While I agree that compatible version negotiation is much easier to design
than incompatible version negotiation, I'm not sure if I'm convinced of the
necessity to have compatible version negotiation.

Innovators can use Transport Parameters to change how short header packets
would be used in the way they want. Depending on how much they change, it
could be an entirely different protocol. But that does not warrant the
necessity of designing a compatible version negotiation mechanism. One can
simply define QUIC_VERSION_123 Transport Parameter. Another person can
define QUIC_VERSION_234. If the server supports both, then the server can
choose from one, and send either of the two to indicate which one has been
chosen.

But even before that, I would point out that in most cases, innovators will
be incentivized to extend v1, because in most cases innovators are
interested in adding one feature at a time to QUIC, rather than designing
everything from scratch. I think that is a good thing for the entire
ecosystem, because we can reuse components, rather than redesigning and
reimplementing everything.


> David
>
> On Tue, Apr 20, 2021 at 11:40 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>
>> 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 <huitema@huitema.net>:
>>
>>> 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
>>> >>
>>> >>
>>>
>>>
>>
>> --
>> Kazuho Oku
>>
>

-- 
Kazuho Oku