Re: New Version Notification for draft-duke-quic-v2-00.txt

Martin Duke <martin.h.duke@gmail.com> Fri, 23 April 2021 15:44 UTC

Return-Path: <martin.h.duke@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 1281F3A1349 for <quic@ietfa.amsl.com>; Fri, 23 Apr 2021 08:44:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OzSb0NP-FMun for <quic@ietfa.amsl.com>; Fri, 23 Apr 2021 08:44:49 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 C66FF3A133D for <quic@ietf.org>; Fri, 23 Apr 2021 08:44:49 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e14so17338300ils.12 for <quic@ietf.org>; Fri, 23 Apr 2021 08:44:49 -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=YnJmoFXFEE9Ne9NJEnZjfcGqspv4nmcsh+uv+z2ZAc4=; b=BW2aSTwkgvqTPfNo7pNQgjUmcmjE2DpcZYXf9fjzG2I0QNizYpIxXK+caXSJDS2kcQ hXkcqXQZudVG4fbtep6Ma0viyof3H5+6ufH2KvqvulToRoZL/dG5ibmPBY7dVaerT5/X 5f9bsbAk9BNMcKsjddCW0n51wNyP314F0GLXvvccwV47Uau8EcO/StvKRKQNMgXcidrm 4Nqyd9fIWss6fi84hZW6Hum8tavWS1mA7W02lGIRJDGSQIrdCzmS0fJ7/BoaCsCMXFlW DT2TQNvyfmmiMWOysTFvDF+Nm6kXZhSu3oROCN+poDb+VFmnpX0JZBTQdetuFzHnC+nX tsYg==
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=YnJmoFXFEE9Ne9NJEnZjfcGqspv4nmcsh+uv+z2ZAc4=; b=P3+vhP3GLsoDQg8XNeIMlKonoM9zKjRt6npPORe2nwPS+8jmaLPOfX6M3x5ev1/gwt Hs7dN42DcW9plvQytai62MndcDNB3cfjo4W9MoRUcIhIaAB2HkcU/uCmClL4KL72h379 ThoeI9Z5xv8eOjXxPgGXyB/Knbp5kBG2GKqz4B8bYuMSmUsEib3KdamfQG1HjDmVEI4q X8XGG4NI++ws3O2AuK8QS3iC8KyZZuj+VLZMljVN5dP5gDYA3NXGwQvRUhD/zLev1LzH 1Uzhp7ie1dmKt+bL7fb7D6qMPVMmMdU5IZL3uN7KfOcsBRKJn9XLeDkXUJZxCuNx75tU CSSw==
X-Gm-Message-State: AOAM532tavWQXSDB6E/pefZwCMoQgGGUDdOI3W30kn7hVDyVAyrWGokb 2N95/l9Ape/x7yUFfC4TFpGyA28x7Lwda/iQFvU=
X-Google-Smtp-Source: ABdhPJze008Mht3/KPvnnot8/4ZxNzSa8NPc+MUhLdZPNX6Nv3vAmEpPpSSgKFyT7eLpJtU4lOPRX4jD/Yh0hTPZMLU=
X-Received: by 2002:a05:6e02:1c42:: with SMTP id d2mr3176339ilg.287.1619192688440; Fri, 23 Apr 2021 08:44:48 -0700 (PDT)
MIME-Version: 1.0
References: <161911211931.14837.5258716888014139826@ietfa.amsl.com> <CAM4esxQqjy6WC_6xo8c27qX_CFoyrGW=CMc-od-pmijkuptOCw@mail.gmail.com> <CALGR9oYewRHFgKYm8eyxQyB=HU7afsm2XFR3YPGW4RD6bQYysQ@mail.gmail.com> <CAM4esxQes0NBv3_o8LqH7ozrg1_i_VMpzS30c-MyNtHg6n6vRQ@mail.gmail.com> <CAOYVs2pgJmtetCifvtT_9MQes9f57w9=oCdNLGFHcTGJSU1OTQ@mail.gmail.com>
In-Reply-To: <CAOYVs2pgJmtetCifvtT_9MQes9f57w9=oCdNLGFHcTGJSU1OTQ@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 23 Apr 2021 08:44:44 -0700
Message-ID: <CAM4esxRPbBLV2VaeQMmQ2eCaCYQa3a=ATxMYRZm4WEE813EpYQ@mail.gmail.com>
Subject: Re: New Version Notification for draft-duke-quic-v2-00.txt
To: Marten Seemann <martenseemann@gmail.com>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000047a1105c0a5ad9f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/8nc4Z0wVA7ca-CfcSDkwughxH9M>
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: Fri, 23 Apr 2021 15:44:55 -0000

Hi Marten,

I believe everything you say is true, but to me the main intent of the v2
draft is in fact to exercise VN.

On Fri, Apr 23, 2021 at 5:29 AM Marten Seemann <martenseemann@gmail.com>
wrote:

> Hi Martin,
>
> Thanks for writing this up. If there's interest in deploying v1 and v2 at
> the same time, we could scratch the requirement to implement the version
> negotiation draft. This would open us up to version "downgrade" attacks,
> but given that the two versions have identical security properties (by
> design), do we actually care?
>
> On the other hand, I'm not sure if deploying v2 right now would actually
> help prevent ossification. Middleboxes are already used to seeing multiple
> QUIC versions on the wire, since we have quite broad deployment of draft
> versions, and some people controlling both endpoints are even using private
> version numbers. One might argue that the one thing that will actually
> prevent ossification won't be shipping one v2, but only proper greasing of
> the field, e.g. by implementing some variant of your version alias draft.
>
> Regards,
> Marten
>
> On Fri, Apr 23, 2021 at 1:22 AM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
>> Hi Lucas,
>>
>> That's a great question that I hadn't considered.
>>
>> The answer depends on what the WG does with the scope of this, and how VN
>> evolves.
>>
>> 1. If it turns out there are some useful v1 patches we want to land here,
>> then there will be some churn.
>> 2. The VN design is baked into v2, and that is not stable yet. While "v2"
>> might never change, an implementation that advertises v2 may in fact
>> instantiate non-interoperable VN designs that should not be aggregated into
>> a single version codepoint (though I'd have to think through how to
>> negotiate through mutating VN designs; I have probably made a conceptual
>> error here). In fact this draft is probably a necessary component to doing
>> proper implementation and testing of compatible VN (unless people keep the
>> draft versions around).
>>
>> IMO if this gets to the point of implementation, it would be wise to use
>> experimental versions until it progresses to RFC. I filed an issue to fix
>> this: https://github.com/martinduke/draft-duke-quic-v2/issues/1
>>
>> Thanks,
>> Martin
>>
>> On Thu, Apr 22, 2021 at 11:07 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
>> wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for writing this up.
>>>
>>> Speaking as an individual, I have some naive questions. Is this document
>>> so trivial that it would never change between revisions? Or is there a risk
>>> that something like initial salt in there might need to rev? To rephrase,
>>> would the document be better off starting with a different QUIC version
>>> value before interoperability discovers a problem and we've blown that code
>>> point? We can always develop such a document with a target code point in
>>> mind for use if the doc were to get adopted and run through all due process.
>>>
>>> Cheers
>>> Lucas
>>>
>>> On Thu, Apr 22, 2021 at 6:52 PM Martin Duke <martin.h.duke@gmail.com>
>>> wrote:
>>>
>>>> Hello QUIC,
>>>>
>>>> I believe it was MT that threatened to do this a long time ago, but to
>>>> work through compatible version negotiation I wrote up a trivial QUICv2
>>>> (below) that just changes the initial salts. This caused me to figure out a
>>>> couple of things about VN that may have been obvious to others but not to
>>>> me.
>>>>
>>>> TL;DR we made the right decision to keep both in the draft.
>>>>
>>>> 1. One very possible world is one where firewalls ossify on expecting
>>>> v1 in the first packet, but don't care about subsequent packets. Compatible
>>>> VN is well-designed for this world, as Client Initials (and 0RTT, sadly)
>>>> can be v1 essentially forever and subsequent packets can be whatever we
>>>> want.
>>>>
>>>> 2. If all versions are compatible, choice of VN method is essentially
>>>> up to the client, but not quite deterministically: it can pick either a
>>>> likely supported version or an unlikely one. If unlikely, the server will
>>>> either accept it or send a VN. If likely, the server MUST use compatible VN
>>>> to change the version, since it can't send a VN packet that contains the
>>>> initial version unless it doesn't have full support for it.
>>>>
>>>> Anyway, this v2 draft is available for your consideration if people
>>>> want to quickly iterate a new version, and/or we need a vehicle for fixes
>>>> to v1.
>>>>
>>>> Thanks
>>>> Martin
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: <internet-drafts@ietf.org>
>>>> Date: Thu, Apr 22, 2021 at 10:22 AM
>>>> Subject: New Version Notification for draft-duke-quic-v2-00.txt
>>>> To: Martin Duke <martin.h.duke@gmail.com>
>>>>
>>>>
>>>>
>>>> A new version of I-D, draft-duke-quic-v2-00.txt
>>>> has been successfully submitted by Martin Duke and posted to the
>>>> IETF repository.
>>>>
>>>> Name:           draft-duke-quic-v2
>>>> Revision:       00
>>>> Title:          QUIC Version 2
>>>> Document date:  2021-04-22
>>>> Group:          Individual Submission
>>>> Pages:          5
>>>> URL:
>>>> https://www.ietf.org/archive/id/draft-duke-quic-v2-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-duke-quic-v2/
>>>> Html:
>>>> https://www.ietf.org/archive/id/draft-duke-quic-v2-00.html
>>>> Htmlized:       https://tools.ietf.org/html/draft-duke-quic-v2-00
>>>>
>>>>
>>>> Abstract:
>>>>    This document specifies QUIC version 2, which is identical to QUIC
>>>>    version 1 except for some trivial details.  Its purpose is to combat
>>>>    various ossification vectors and exercise the version negotiation
>>>>    framework.  Over time, it may also serve as a vehicle for needed
>>>>    protocol design changes.
>>>>
>>>>    Discussion of this work is encouraged to happen on the QUIC IETF
>>>>    mailing list quic@ietf.org or on the GitHub repository which
>>>> contains
>>>>    the draft: https://github.com/martinduke/draft-duke-quic-v2.
>>>>
>>>>
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>>