Re: Version Ossification: Intended Scope for QUICv1

[Roberto Peon <[e-mail]>]

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]<mailto:[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