Re: Version Ossification: Intended Scope for QUICv1

[Eric Rescorla <[e-mail]>]

I would actually like to suggest something more aggressive (or,
conservative, if you prefer), namely that we punt version ossification
entirely to the future, whether to an extension or QUIVc2. In support
of this proposal, I would make three points:

- We are actually going to be running concurrent versions for quite
  some time. Even if everyone were to aggressively (say 6-12 months)
  deprecate all the draft versions upon shipping the RFC, we're
  looking at something that's 18-24 months out. And of course,
  I expect people to do some simple version greasing. So, that
  probably buys us some time before real bad ossification sets
  in.

- It's turning out to be surprisingly hard to design a mechanism that
  works, as evidenced by David's mechanism. And to that, I would add
  that anything that involves having a server hand out some new set of
  keys/salts is going to run into the same kind of multi-CDN problems
  we had with ESNI (i.e., failures when you get switched between
  CDNs). And then recovering from that cleanly either seems to mean
  some ESNI-style fallback or allowing a middlebox to forge VN to
  force you back to the published version/salt.

- It seems like this would all be a lot easier if we had ESNI, because
  you could tie the use of the new salt/version to the ESNIConfig
  (either as a public or symmetric key, depending on taste).

So what I would propose is that we put this problem on ice for now and
then revisit it as an extension. All of the proposals that we have
seen seem like they could be done as an extension, and then we can (1)
get QUICv1 done and (2) hopefully leverage ESNI once we have some
experience.

-Ekr

On Thu, Oct 31, 2019 at 2:13 PM David Schinazi <[e-mail]>
wrote:

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