Re: QUIC ossification

[David Schinazi <[e-mail]>]

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