Hi Christian, I'm in the process of changing the Retry Integrity tag, as you suggest.
Question for you: would it be best to change the HKDF labels to get total key separation between v2 and v1? That seems cleaner but I don't want to create too much additional work for you. Martin On Sat, Apr 24, 2021 at 9:10 PM Christian Huitema <[email protected]> wrote: > I just implemented in picoquic the compatible version negotiation > defined in https://github.com/quicwg/version-negotiation/, 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 > https://github.com/private-octopus/picoquic/pull/1202. 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, https://github.com/quicwg/version-negotiation/issues/19 > . > > 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 > https://github.com/quicwg/version-negotiation/issues/35 > > 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: > https://github.com/quicwg/version-negotiation/issues/39. > > 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 <[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 > >>>>>> > >>>>>> > >>>>>> > > > >
