Re: QUIC ossification

[Roberto Peon <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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.)