Re: Version Ossification: Intended Scope for QUICv1

[Eric Rescorla <[e-mail]>]

On Mon, Nov 11, 2019 at 6:01 PM Marten Seemann <[e-mail]>
wrote:

> 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.
>
>
> I'm not sure if I can agree with this assessment. While we will have
> multiple QUIC versions deployed at the same time, the salts used to encrypt
> the Initial packets are all public. Middlebox vendors can easily build a
> device that is able to decrypt any of these versions.
>

ISTM that this is the scenario of interest for QUICv2 as well, namely that
the protocol will be public but vendors will have to adapt. If they do that
by reading specs and updating prompt, that seems not ideal but acceptable.

-Ekr

The fact that draft versions + QUIC v1 will (hopefully) work tells us
> little about how middleboxes will handle unknown version, i.e. versions
> that they don't know how to decrypt. This suggests to me that building a
> greasing mechanisms which ensures that packets with unknown version numbers
> are sent over the wire is essential for QUIC v1.
>
> On Tue, Nov 12, 2019 at 5:39 AM Roberto Peon <[e-mail]> wrote:
>
>> I would love to see a v2 that intends to address this chartered before
>> agreeing that this shouldn’t be included.
>>
>> -=R
>>
>>
>>
>> *From: *QUIC <[e-mail]> on behalf of Ian Swett <ianswett=
>> [e-mail]>
>> *Date: *Monday, November 11, 2019 at 8:58 AM
>> *To: *Christian Huitema <[e-mail]>
>> *Cc: *David Schinazi <[e-mail]>, Eric Rescorla <
>> [e-mail]>, QUIC <[e-mail]>
>> *Subject: *Re: Version Ossification: Intended Scope for QUICv1
>>
>>
>>
>> +1 from me as well.
>>
>>
>>
>> I think this is useful work and I support the QUIC WG working on it, but
>> I don't believe it needs to be included in v1 and I'd like to get some
>> deployment experience with it before standardizing it.
>>
>>
>>
>> On Sun, Nov 10, 2019 at 7:48 PM Christian Huitema <[e-mail]>
>> wrote:
>>
>>
>> On 11/10/2019 2:53 PM, Eric Rescorla wrote:
>> > 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.
>>
>> +1
>>
>> -- Christian Huitema
>>
>>