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

[Martin Duke <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]
> >
> >> 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 <[e-mail]>
> >>> 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
> >>>> <[e-mail]>
> >>>> 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 <[e-mail]
> >
> >>>>> 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: <[e-mail]>
> >>>>>> Date: Thu, Apr 22, 2021 at 10:22 AM
> >>>>>> Subject: New Version Notification for draft-duke-quic-v2-00.txt
> >>>>>> To: Martin Duke <[e-mail]>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 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 [e-mail] 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
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
>