Re: Version Ossification: Intended Scope for QUICv1

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


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