Re: QUIC ossification

[Martin Duke <[e-mail]>]

Collective, time for me to file a github issue? Or leave it on the list?

On Thu, Feb 14, 2019, 12:54 PM David Schinazi <[e-mail]
wrote:

> 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 <
>> mt@lowentropy..net <[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.
>>
>>