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 <[email protected]> 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 <[email protected]> > 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: https://github.com/martinduke/draft-duke-quic-v2/issues/1 >> >> Thanks, >> Martin >> >> On Thu, Apr 22, 2021 at 11:07 AM Lucas Pardue <[email protected]> >> 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 <[email protected]> >>> 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 >>>> >>>> >>>>
