Re: QUIC ossification

[Martin Thomson <[e-mail]>]

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