Re: Tacking stuff on to VN packets

Martin Duke <> Tue, 11 May 2021 20:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F37663A2571 for <>; Tue, 11 May 2021 13:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lz_Qm0wMW-mg for <>; Tue, 11 May 2021 13:30:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8808F3A256F for <>; Tue, 11 May 2021 13:30:40 -0700 (PDT)
Received: by with SMTP id o9so13172027ilh.6 for <>; Tue, 11 May 2021 13:30:40 -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=WKvdXgakkdhPqiRe6sNC0Q7kvXn4qMcWQEzYHqi4dgE=; b=aomCmrjkXFZAros9F3BIdxMLTSufknKclqCql9BOX+sLyvwmml4or+AG49kRblGpfC xo+/VN5NRzigcZZRjoedkoWUDE2oyIlfqyJCPNLfx+PURnjbuPljaLU1r2iM37d+praW RUgqvJgNxUPOMb+Kqw4tnymd3lu1e9DpGwIFwfa80LmnVYzb6VLwpSJryP8B1Xyv985i +3n5DAm2U5K/hrMjc61V7cqWaHb5SIHxtjkDe19HAqMZXuGIlYFHwDMvHO2niL60MQzZ 6ymHvDeA7ICznI6X+JPS9G2iDnMFCzXDayo84mojseqPaE2mWmX8Q0OymSFKZRYgsfCQ HGQg==
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=WKvdXgakkdhPqiRe6sNC0Q7kvXn4qMcWQEzYHqi4dgE=; b=IhMvb/C+gJtk4kH25uYdYoKXA1h6kRx4uQi2GwNG4FceCtwlFRwqAyqDqhH71VvrlM S6JmZrFxrTN3cnNVhPZFEFL62nB5BZvSAjJFzAN+rOQKQo45WzJNM0BIglPG2pTUi9Gw oU1iXOvhi6xs3oH9j8KV/rDC1i7ox8njlaZPRqflAk1QeT2LKNz8suqsHVir8CxG0JhB BJRP47uvx12nYBtl7tan+btkVLWAq0NTyWqx8Xx2JP8qSLyxD62TSBz8/eqUrQgitPe/ f5Ny7VbjmdzKpax0ucyOQVQ6IB596SEoZz/G+ZMO+xCT0LiMZSn6QpW5526zjUuEyLA6 Kn5Q==
X-Gm-Message-State: AOAM531oCPfA9GSN7pusTdHuh8ivnbfilbgXyYL9l/eOhkgGwl5yUa7h ox8JVrLAOgyqz8WYAcKkA9t8esAfoNDtWvfdLeU=
X-Google-Smtp-Source: ABdhPJy+bRLFOKCG5IOISAXK4CH/Pc9yOONI9dCDtaPoU7qwDLQKL9x1xfkwPlcC4cARl0WZvdcXyUIvN9j3qjhS9Ck=
X-Received: by 2002:a92:c78b:: with SMTP id c11mr27706878ilk.249.1620765038161; Tue, 11 May 2021 13:30:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Tue, 11 May 2021 13:30:27 -0700
Message-ID: <>
Subject: Re: Tacking stuff on to VN packets
To: David Schinazi <>
Content-Type: multipart/alternative; boundary="0000000000005d340505c213c4ed"
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: Tue, 11 May 2021 20:30:45 -0000

Ah, perhaps I'm misinterpreting this to mean that that data  is in the VN
packet itself. I accept that your reading probably makes more senese.

On Tue, May 11, 2021 at 10:43 AM David Schinazi <>

> Can you clarify why you want to remove that text from invariants? It seems
> correct to me: it states that the VN packet conveys Supported Versions
> without a way to authenticate this data. Other protocol elements can
> authenticate the data. For example,  draft-ietf-quic-version-negotiation
> does allow endpoints to detect modification or corruption in the set of
> supported versions.
> David
> On Tue, May 11, 2021 at 10:28 AM Martin Duke <>
> wrote:
>> > What problem are you trying to solve with this trailer?
>> For the purposes of this discussion, I'm wondering about this idle
>> speculation in the invariants draft. Having this field would simplify some
>> problems in an individual draft I'm working on, but there are other ways to
>> fix it.
>> If no one is going to say "Yes we should have this capability" then we
>> can either excise the text from invariants or, at this late stage, at least
>> have an understanding that this text doesn't mean anything.
>> Martin
>> On Tue, May 11, 2021 at 10:18 AM David Schinazi <>
>> wrote:
>>> Unfortunately that won't work. Supporting multiple versions of QUIC does
>>> not require supporting any document, apart from the QUIC invariants. And
>>> the invariants don't reserve space for a trailer after the Supported
>>> Versions field. What problem are you trying to solve with this trailer? I
>>> suspect there are easier ways of solving it.
>>> David
>>> On Tue, May 11, 2021 at 10:11 AM Martin Duke <>
>>> wrote:
>>>> Section 6 of invariants
>>>> <>
>>>> sayeth:
>>>> "Version Negotiation packets do not use integrity or confidentiality
>>>> protection. Specific QUIC versions might include protocol elements that
>>>> allow endpoints to detect modification or corruption in the set of
>>>> supported versions."
>>>> I also vaguely remember ekr batting around the idea of tacking some
>>>> data onto the packet  to solve a problem we were discussing.
>>>> *Maybe we just don't want to do this at all and we can safely ignore
>>>> this text in invariants.*
>>>> If we *do* want to do it, the design is a little problematic. There is
>>>> no length field in VN packets to signal that the supported version list is
>>>> ending and other stuff is beginning.
>>>> The only way I can think of to make this work is to use the VN draft to
>>>> reserve a magic version number to mean "this is the end of the supported
>>>> version list". That version is not a real version, MUST be the last one
>>>> listed, and perhaps can be followed by another magic number to indicate the
>>>> content that follows.
>>>> Leaving aside legacy stuff negotiating pre-standard versions, which
>>>> will hopefully go away someday, someone supporting multiple versions would
>>>> be REQUIRED to support the VN draft and therefore incorporate this change.
>>>> Thoughts?
>>>> Martin