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

From: Martin Duke <[email-masked]>
Date: Thu, 22 Apr 2021 10:52:13 -0700

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

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-masked] 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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 22 Apr 2021 19:07:37 +0100

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-masked]> 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.
>
> 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
> 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
>
>

---

From: Martin Duke <[email-masked]>
Date: Thu, 22 Apr 2021 11:21:37 -0700

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-masked]>
wrote:

> 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
>> Html:
>> https://www.ietf.org/archive/id/draft-duke-quic-v2-00.html

---

From: Marten Seemann <[email-masked]>
Date: Fri, 23 Apr 2021 19:29:47 +0700

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-masked]> wrote:

>>> URL:
>>> https://www.ietf.org/archive/id/draft-duke-quic-v2-00.txt

---

From: Martin Duke <[email-masked]>
Date: Fri, 23 Apr 2021 08:44:44 -0700

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-masked]>
wrote:

>>>> 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
>>>> 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
>>>>
>>>>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Apr 2021 12:38:27 -0700

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Apr 2021 21:09:33 -0700

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:
>>>>>>     version 1 except for some trivial details.  
Its purpose is to 
>>>>>> combat

---

From: Martin Duke <[email-masked]>
Date: Mon, 26 Apr 2021 11:34:24 -0700

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-masked]>
wrote:

> >> On Fri, Apr 23, 2021 at 5:29 AM Marten Seemann <[email-masked]
> >
> >> wrote:
> >>
> >>> Hi Martin,
> >>>
> >>>>> On Thu, Apr 22, 2021 at 6:52 PM Martin Duke <[email-masked]
> >
> >>>>> wrote:
> >>>>>
> >>>>>> Hello QUIC,
> >>>>>>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 28 Apr 2021 08:31:32 +1000

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:
> (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.
> 
> 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.
> 
> 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.
> 
> want to quickly iterate a new version, and/or we need a vehicle for 
> fixes to v1.
> 
> Thanks
> Martin
> 
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 27 Apr 2021 16:06:38 -0700

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-masked]> 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.
>