QUIC ossification

[Martin Duke <[e-mail]>]

Mark's last call for design issues led me to think about ossification
issues. We have done just about everything we can to prevent ossification.
There's a thread elsewhere about the QUIC bit, but beyond that I see two
big concerns.

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.

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 don't have great solutions to either of these, but I think these are
issues worth discussing given the effort we've put into blocking
ossification. If we can't adequately punish misbehaving middleboxes via
greasing-like behaviors, then we should at least have contingency plans if
the ossifiable fields do, in fact, ossify.

If this is a fruitful discussion area, I'm happy to file a github issue.