Subject: Version Ossification: Intended Scope for QUICv1

From: David Schinazi <[email-masked]>
Date: Thu, 31 Oct 2019 14:12:46 -0700

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

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 1 Nov 2019 06:33:48 +0900

Hi David,

Thank you for summarizing the high-level options. I think it's very useful
to have this discussion.

Please see my comments below.

2019年11月1日(金) 6:13 David Schinazi <[email-masked]>:

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

I dispute the argument that #3166 is more complex. My view is that #3166 is
more powerful and simpler than (3) (the PR being #2573).

Reasons:
* For a server associating one initial salt with one alternative version,
#3166 and #2573 are identical with the exception being how the information
is carryied (i.e. TP vs. NEW_TOKEN).
* For a client, bundling the alternative seeds in a NEW_TOKEN makes things
simpler, as clients are not required to have a new state that has to be
retained across multiple connections.

> forget their token keys, and mitigations for that problem can become

The proposal for 3 has this problem. It leads to a failure when a server
forgets the alternative initial salts.

> mitigations without delay.

As stated, the proposed solution for (4) is simpler than (3), can be used
to implement (3), and also provides a stronger protection for servers
certain that they can retain the token unprotection keys.

I agree that solving (5) for all parties might be hard, and that we might
want to punt that to v2. But, I think we should adopt (4) than (3) due to
the aforementioned reasons.

-- 
Kazuho Oku