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
