Well you beat me to it. Another nit to add to the pile: it might pay not to use 2 as the version number here. Pick a random number, like 0xfaceb00c or something.
As for the labels we use for HKDF, tweaking those might be a good idea. We didn't do that for draft versions, but a completely new version would benefit from better separation. On Fri, Apr 23, 2021, at 03:52, 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: <[email protected]> > Date: Thu, Apr 22, 2021 at 10:22 AM > Subject: New Version Notification for draft-duke-quic-v2-00.txt > To: Martin Duke <[email protected]> > > > > 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 [email protected] 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 > >
