[quicwg/base-drafts] Simplify version negotiation (#2133)

[ekr <[e-mail]>]

Following the discussions in BKK I've been thinking about version
negotiation a bit, and I think we can improve things while also
simplifying them. The TL;DR version of this is that instead of having
the client send any version and the server correct it, the client
offers a list of versions and the server picks one. This makes
things a lot simpler at the cost of some unnecessary flexibility.


DETAILS
The basic insight is that the current VN process is complicated
because it's got an axis of flexibility we don't need, namely allowing
the client to send an Initial packet with no idea whatsoever of what
the server supports. This means that you have to be able to have the
server blindly generate a VN no matter what the client sends, which
has the following negative consequences:

- It burns up a round trip if the client's initial version is not
  the one the server wants, even if the client and server are
  basically compatible.

- We want it to be stateless, so we have this clumsy validation
  procedure.

What I propose is a simpler approach, which is pretty much what
all other other IETF protocols that do version negotiation do:

- The client sends an Initial packet using a version which is
  acceptable to every server for a given application (e.g., Web,
  e-mail, etc.). This packet contains a list of the versions
  the client supports.

- The server responds with its preferred version out of this list.

- If the client's Initial packet is totally incomprehensible to
  the server, then you get a hard failure (and we repurpose
  and simplify VN for this).

This has the following advantages:

- All version negotiation happens in one round trip.

- Negotiation validation is mostly a matter of checking that the
  server-selected version is acceptable [0].

The main cost is that the client needs to be able to safely send an
Initial that can be read by the server, which means that it needs to
agree with the server on Initial format, though this can span multiple
QUIC versions.

Importantly, this doesn't preclude having totally incompatible
versions of QUIC (e.g., with a different CRYPTO handshake). You can
obviously have two disjoint sets of clients and servers that support
QUIC X and QUIC Y. Additionally, the case where you have a server
which supports A and B and clients which either support A or B works
fine.  The client's version appears in the header and the server can
demux on that. So, it's not like we're promising that every version of
QUIC has the same CRYPTO values, just that the client knows enough
about the server to know an Initial format it will accept.

What won't work is where the client has no knowledge of the server's
capabilities at all, specifically where (a) the client supports
incompatible versions A and B and (b) the server might support only A
or only B and the client doesn't know which one.  It's not clear how
this could happen in practice; it's like the client wanting to speak
either TLS or SSH and not knowing which one the server speaks [1].


[0] You also want to put the server's selected version in the crypto
handshake, so you need to check that the inner and outer versions
match.

[1] If we ever did want this, we could always design it as an
extension later, presumably cribbing from the current VN design.



You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2133

-- Commit Summary --

  * Refactor
  * Versions
  * Version error
  * Add vesions back to VE
  * Remove VN from recovery
  * Remove version list from VE

-- File Changes --

    M draft-ietf-quic-recovery.md (12)
    M draft-ietf-quic-transport.md (309)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2133.patch
https://github.com/quicwg/base-drafts/pull/2133.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2133