Re: Version Ossification: Intended Scope for QUICv1

[Kazuho Oku <[e-mail]>]

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

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.


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

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


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

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.


> Thoughts?
>
> David
>
>
>

-- 
Kazuho Oku