Re: QUIC ossification

[David Benjamin <[e-mail]>]

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