Re: QUIC ossification

[David Schinazi <[e-mail]>]

Yes, the version downgrade prevention was punted to whenever we start using
another production version and performing in-band version negotiation.
These rolling versions would qualify as such and absolutely require
downgrade prevention if we have version negotiation inside QUIC.

That said, an important difference between TLS and QUIC here is Alt-Svc. We
don't need 100% of QUIC uses to use this rolling version to prevent
ossification, it would be fine if only HTTP/3 clients did that.
Those clients will know the server-supported versions thanks to Alt-Svc, so
there is no need for in-band version negotiation between these versions.

It would be feasible to deploy these rolling versions while still treating
any Version Negotiation packet as a critical error.

David

On Thu, Feb 14, 2019 at 12:42 PM Mike Bishop <[e-mail]> wrote:

> We actually agreed at the interim to leave downgrade protection as future
> work, since this is currently the only version we care about.  A future
> version would need to be accompanied by an extension to v1 that provides
> downgrade protection.  🙂
>
>
>
> If we start actively flexing version negotiation, of course, we probably
> need to revisit that decision.
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * David Benjamin
> *Sent:* Thursday, February 14, 2019 12:39 PM
> *To:* Mikkel Fahnøe Jørgensen <[e-mail]>
> *Cc:* Jana Iyengar <[e-mail]>; QUIC WG <[e-mail]>; Martin
> Thomson <[e-mail]>
> *Subject:* Re: QUIC ossification
>
>
>
> At least in the TLS incarnation of this idea, yes, the point would be to
> support both V1 (for normal clients) and the rolling version.. That does
> not require the client reject V1 for this to work, presuming your version
> negotiation has downgrade protection. (Being forced onto a version other
> than what you would have naturally negotiated is a downgrade.)
>
>
>
> I'm not familiar with QUIC's negotiation mechanisms, but I certainly hope
> you all are downgrade-protected. That's generally important independent of
> these kinds of games.
>
>
>
> David
>
> On Wed, Feb 13, 2019 at 11:59 PM Mikkel Fahnøe Jørgensen <
> [e-mail]> wrote:
>
> Version of the month is problematic:
>
>
>
> Google server would need to support a basic V1, otherwise non-chrome user
> agents would fail. Chrome browsers would have to reject V1 or the greasing
> won’t work. This can only happen towards Google servers. Middleboxes now
> check for V1 or Google domain. Eith future encrypted request domain, it is
> a perfect wsy to firewall Google via Chrome. Users switch to other browser.
>
>
>
>
> ------------------------------
>
> *Fra:* QUIC <[e-mail]> på vegne af Martin Thomson <
> [e-mail]>
> *Sendt:* torsdag, februar 14, 2019 6:08 AM
> *Til:* Jana Iyengar
> *Cc:* QUIC WG
> *Emne:* Re: QUIC ossification
>
>
>
> On Thu, Feb 14, 2019, at 15:48, Jana Iyengar wrote:
> > Basically, I'm proposing that QUIC v1 be assigned a random number for
> its
> > version at RFC publication time.
>
> What property do you expect that to provide?
>
> > Anyone who wants to use a different version for v1 MUST request it from
> IANA first before using it in the wild.
>
> This too. What does this achieve?
>
> I get that there seems to be the emerging view that unmanaged codepoint
> space is not good and we should ask IANA to manage it for us, but I don't
> understand what these proposals would provide.
>
>