Version Ossification: Intended Scope for QUICv1

[David Schinazi <[e-mail]>]

Hi folks,

The conversation around version ossification has been really interesting
since Cupertino. But at least for me it's reached a level of complexity
that warrants taking a step back and looking at what we're trying to solve.
Here's my understanding of where we are:

1) In Cupertino there was consensus in the room to do something to mitigate
ossification of QUICv1.

2) The solution that folks liked was to have a concept of alternative
versions and alternative salts that act like QUICv1 but are encoded
differently over the wire.

3) A concrete proposal for (2) was for servers to have their own set of
(alternative_version, alternative_salt) pairs, then transmit a random pair
from that set to each client (i.e. via transport parameters). The server
can then reconstruct the alternative_salt just by seeing
the alternative_version.

4) Kazuho proposed a solution (#3166
<https://github.com/quicwg/base-drafts/pull/3166>) that was both more
powerful and more complex: tie the (alternative_version, alternative_salt)
pair to NEW_TOKEN frames, to allow servers to generate a
unique alternative_salt per client and encode it in the token.

5) After some interesting back and forth on that PR, it became clear that
this is a hard problem to solve: this could cause failures if servers
forget their token keys, and mitigations for that problem can become
downgrade attack vectors

6) While there was clear WG appetite for (1), I'm not sure we have
consensus to build a more powerful solution like (4)

I fear that solving (5) could take some time, which would delay QUICv1.
Instead I'd like to propose the following plan:
a) we take the simpler solution (3) and add that to the spec
b) we take the more powerful/complex solution (5) a turn it into a QUIC
extension

That would allow us to ship QUICv1 with some level of ossification
mitigations without delay.

Thoughts?

David