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

Christian Huitema <> Sun, 25 April 2021 04:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E4BE3A2DB9 for <>; Sat, 24 Apr 2021 21:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gBCe3IgB7iku for <>; Sat, 24 Apr 2021 21:09:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D421F3A2DB6 for <>; Sat, 24 Apr 2021 21:09:50 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1laW5V-000yvI-CV for; Sun, 25 Apr 2021 06:09:46 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4FSZKp5v8jzP3D for <>; Sat, 24 Apr 2021 21:09:34 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1laW5O-0005Jy-Lr for; Sat, 24 Apr 2021 21:09:34 -0700
Received: (qmail 30811 invoked from network); 25 Apr 2021 04:09:33 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 25 Apr 2021 04:09:33 -0000
From: Christian Huitema <>
To: Martin Duke <>, Marten Seemann <>
Cc: IETF QUIC WG <>, Lucas Pardue <>
References: <> <> <> <> <> <> <>
Subject: Re: New Version Notification for draft-duke-quic-v2-00.txt
Message-ID: <>
Date: Sat, 24 Apr 2021 21:09:33 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.08)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+oWVoqIVfUSV9IfIhe8AtYPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCFmz RJ0ei8j5shPIvPrCUTrmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca+xnn3Ohf8XY5WZ+f/Kk3UxQ6V51u76v35b1wNe/MvdKAGdwU TZKlze5ERymXAD3v2+J9PgaoF8SQHto3le4zsAApCVB1N/BtJyJqv7YkIyyKggeTQ85o+W6+jEZD z+LhiyQEs+dlGXUJLWZ+Gc08Nmllke3azHdKmySKNUVQl4ntlVxnbS8qIO7oudHyb2T1VQ58xe/l rqiRGalI3YPsxOTrFXToVyBmRCgQVX6zVyFUu8qzeMQP6uTHL0d9UjfY+eX5ZvcELCIKs663F/co VFYFvf25LVONYbYifH5OzZDcG6hsRQZiAIgw+z837AqgX7ewI8e1h7RITgN14BHmGVt/ReJ9Mfhz zmbKTH7wI9GEU1utNskUAORCV2WFZX0jhrJxyKF1H9pcTl8EDZi+w17lLXQUcNAszDsnoUOr0BiK EJKz/RmBsQtebYIhwEXMOI+gTB/pfSlbi1HgG7umZ25gpnihbI3Vv1c2tRvdVD2GbN7BITAZon7Z Iz1ONK9yUo4/+EUytKrR9Md9I2Rs12KKF4yMfZlQjjzYRzF0zixPCC/cRgvQKtcrMMueERx3swYy 6We66q1J60t6NoB9IPmfTY/3EjENT+OGABNtD0ILVMcScraAEu0RqZMYbqf5PH0pOF/JpGJ/A4RZ FqrBIH6m+UeFXprlCOm3BAEbJtAT1BYHStA0OogdNtRxnRSLF+XCKxIG9XMEgRDdaWpvCv+zESlk TxdSCNcDfRohcehWBb39uS1TjWG2Inx+Ts2QNOYPIz4ynMa7pZQ4hi/HGtuWeHzx9sLaQmDwvYQn 76e9NXttZBkk6PeFqH6So31P
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: Sun, 25 Apr 2021 04:09:56 -0000

I just implemented in picoquic the compatible version negotiation 
defined in, using 
Martin's draft V2 version as a test case. The unit tests validate a 
negotiated update from v=0x00000001 to v=0xff010000. For those who like 
to look at code, the picoquic PR is at I found a few 
issues when doing that implementation:

1) The server fills the version_negotiation TP with the negotiated 
version and the complete list of supported version. The client checks 
that the negotiated version is being used, but ignores the list of 
supported versions. Do we really need to transmit that? The is already 
an issue for that,

2) In case of incompatible upgrades, the client sends the original 
version and the list of versions proposed in the VN. The server checks 
the original version to detect a downgrade attack, but just ignores the 
list of versions proposed in the VN. That's me being lazy. I suspect I 
won't be the only lazy one. Issue

3) Synchronization is hard. The server knows the negotiated version at 
the end of the client first flight. My implementation assume that the 
server uses this negotiated version for its own first flight. The client 
monitors the incoming version numbers; if it sees a change to the 
compatible version, it upgrade its own context, starts using the new 
version, then validates that upgrade when receiving the server's TP. 
This gets more complicated if we consider packet losses, issue:

I also think that we need to rethink the protection against spoofed 
incompatible versions. The client signals its current version, the 
original version, and a list of compatible versions. Admittedly, the 
client prefers the compatible versions to both the current and original 
version, so if the server negotiates a compatible version life is good 
and there is no point worrying about downgrades. If there is no 
compatible version and the server supports the original version, it 
could negotiate that too, which would largely mitigate the downgrade 
attack. Why exactly do we insist on tearing down the connection?

-- Christian Huitema

On 4/23/2021 12:38 PM, Christian Huitema wrote:
> Martin,
> For V1, we had a rule that the version "0x00000001" would only be used 
> after we had finalized the RFC. Before that, drafts would define 
> versions such as "0xFF00001D" for draft 29. Should you not follow a 
> similar mechansim, and define something like version "0xFF0100nn" for 
> the draft-nn of the V2 spec?
> -- Christian Huitema
> On 4/23/2021 8:44 AM, Martin Duke wrote:
>> 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 <>
>> 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 <>
>>> 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