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

Martin Duke <> Fri, 23 April 2021 15:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1281F3A1349 for <>; Fri, 23 Apr 2021 08:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OzSb0NP-FMun for <>; Fri, 23 Apr 2021 08:44:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C66FF3A133D for <>; Fri, 23 Apr 2021 08:44:49 -0700 (PDT)
Received: by with SMTP id e14so17338300ils.12 for <>; Fri, 23 Apr 2021 08:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 23 Apr 2021 08:44:44 -0700
Message-ID: <>
Subject: Re: New Version Notification for draft-duke-quic-v2-00.txt
To: Marten Seemann <>
Cc: Lucas Pardue <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000047a1105c0a5ad9f"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>

> 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 <>
> 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:
>> Thanks,
>> Martin
>> On Thu, Apr 22, 2021 at 11:07 AM Lucas Pardue <>
>> 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 <>
>>> 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: <>
>>>> Date: Thu, Apr 22, 2021 at 10:22 AM
>>>> Subject: New Version Notification for draft-duke-quic-v2-00.txt
>>>> To: Martin Duke <>
>>>> 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:
>>>> Status:
>>>> Html:
>>>> Htmlized:
>>>> 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 or on the GitHub repository which
>>>> contains
>>>>    the draft:
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at
>>>> The IETF Secretariat