Re: QUIC ossification

[Ian Swett <[e-mail]>]

Previously David Benjamin suggested spinning a new version of QUIC in
Chrome for every Chrome milestone with the only change being the version
number and the Initial keys.  I'd be curious how the WG feels about that
idea?

On Wed, Feb 13, 2019 at 11:17 AM Martin Duke <[e-mail]>
wrote:

> I agree that a fast v2 would help here. However, it's hard to count on a
> fast IETF process, and even then the middlebox can be pretty dumb and still
> drop version > 2.
>
> I agree that David's scheme, by having the Initial be a v1 packet, may get
> that one through. But then you have subsequent long headers with the new
> version, which may still end badly.
>
> I don't see a good solution here, right now. Although it shouldn't be
> written in the spec, the working group should have some sort of contingency
> plan for how to proceed if the version field ossifies.
>
> On Tue, Feb 12, 2019 at 4:21 PM Roberto Peon <[e-mail]> wrote:
>
>> I don’t have an opinion on how version is negotiated yet.
>> I’m not convinced it is easy to get right. It may be more correct for me
>> to say that I’m convinced it is reasonable difficult to get right because
>> it is the most important of the various invariants.
>>
>> I also suspect that you need more than one way to do it, e.g. in-band and
>> out-of-band (which could be in-band in a V2 to allow for upgrade to
>> something else). Then does a client cache the version? For how long/where?
>> Per IP? Hostname? (blah blah.. etc. etc.)
>>
>> I can say that the ALPN and NPN approaches each had their positives and
>> negatives, and in the end, having something like either is probably good
>> enough.
>>
>> Rather than an opinion on how it should be done, I have an opinion that
>> we need to add this soon, as a V2.
>>
>> -=R
>>
>>
>>
>> *From: *David Schinazi <[e-mail]>
>> *Date: *Tuesday, February 12, 2019 at 4:13 PM
>> *To: *Roberto Peon <[e-mail]>
>> *Cc: *Martin Thomson <[e-mail]>, "[e-mail]" <[e-mail]>
>> *Subject: *Re: QUIC ossification
>>
>>
>>
>> I think we may be able to limit ossification of version numbers by adding
>> some GREASE to the (upcoming) in-band compatible version upgrade extension
>> (what used to be EKR's PR). The idea of that extension is that the client
>> sends a QUICv1 initial containing a transport parameter indicating it
>> supports this extension and what versions of QUIC it supports. The server
>> can then send its replies with a new QUIC version number. Back to GREASE:
>> one option here would be for us to burn some versions for "v1 compatible
>> version negotiation greasing" (similar but different to 0x?a?a?a?a) and
>> servers can in-band upgrade to those versions. But we could also do that in
>> the reverse direction: the servers advertise support for one of these in
>> Alt-Svc and clients send their Initial to that version, and the server can
>> then perform in-band version change to v1, to another of these versions, or
>> just keep the client's version for the life of this connection. This will
>> cause ossifying middleboxes to break these connections.
>>
>>
>>
>> Thoughts?
>>
>>
>>
>> David
>>
>>
>>
>> On Tue, Feb 12, 2019 at 2:15 PM Roberto Peon <[e-mail]> wrote:
>>
>> My fear/experience around this is why I'd strongly recommend doing a QUIC
>> V2 as soon as possible where the delta from V1 -> V2 is limited to *solely*
>> what is necessary for version negotiation.
>>
>> We can simultaneously have a V3 conversation which would  include
>> whatever else we decide we need to change/add as a separate conversation
>> which depends on V2.
>>
>> -=R
>>
>> On 2/12/19, 1:36 PM, "QUIC on behalf of Martin Thomson" <
>> [e-mail] on behalf of [e-mail]> wrote:
>>
>>     On Wed, Feb 13, 2019, at 08:18, Martin Duke wrote:
>>     > 1) Version. I can't think of any immediate negative consequences
>> for a
>>     > middlebox that drops any long header with a version > 1. TLS 1.3
>> had to
>>     > surrender to this problem by hiding the version elsewhere.
>>     >
>>     > We might avoid this by routinely coalescing long headers with random
>>     > version fields to connection-critical packets. Beyond that, I'm out
>> of
>>     > great ideas. If we don't have a robust defense against this, we
>> ought to
>>     > put some thought into how to deploy a v2 if the version fields is
>>     > inoperable.
>>
>>     As Mike points out, the Length field is version-specific, so there is
>> no real defense here other than - as many have suggested - using the
>> version field actively.  That means shipping another version.  In a sense,
>> the fact that Google are still not on the same version gives us some time,
>> but it could mean that we might want to look toward having the "add version
>> negotiation and fallback protection" draft define a version rather than an
>> extension.
>>
>>     > 2) Client Transport Parameters. Initial Keys will help a little
>> bit, but in
>>     > TLS1.3 CCS still sorta exists because middleboxes are inspecting
>> packets so
>>     > deeply. It's not viable for v2 to have the same transport
>> parameters; it's
>>     > only slightly less gross to send v2 client TPs in some later
>> message and
>>     > have to send a fairly bulky "fake" set of v1 TPs in the client
>> hello to get
>>     > through the network.
>>
>>     I'm not concerned about transport parameters if the above issue is
>> fixed.  TLS had no real issues with extensions, and it looks like we
>> already have the start of a pipeline of extensions coming.  v2 can share
>> the transport parameter extension, unless we decide to change the format in
>> a non-compatible way.
>>
>>     (Note: CCS in TLS 1.3 only exists because middleboxes were inspecting
>> a lot, yes, but it also indicates that they weren't inspecting enough,
>> because the compatibility hack we have wouldn't work if they did a proper
>> job.)
>>
>>
>>