I'm mildly resistant to this, but I filed https://github.com/martinduke/draft-duke-quic-v2/issues/4
On Tue, Apr 27, 2021 at 3:32 PM Martin Thomson <[email protected]> wrote: > 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 > > > > > >
