Re: Is "Version Greasing" a new benfit or a new obstacle?

["Martin Thomson" <[e-mail]>]

It's always possible to come up with a scenario where the network helps here, but the cost of help is the risk of harm.

I would cast this question differently: who has the right(?) to decide when a new version of the protocol is permitted?  The motivation behind this is that it is considerably more likely if only endpoints are involved in that process.

The architectural consequences of protecting a "clean" version negotiation process are what makes me positive about this change.  It is always possible to invent a new version negotiation process that looks very much like QUIC v1, but enables the use of v2.  That is what we ended up doing for the TLS 1.2 to 1.3 transition.  For instance, you could learn that you can negotiate QUICv2 by changing the case of certain characters in the server_name extension.  Or you could use the ordering of transport parameters to signal the support for an alternative version.  If you are willing to tolerate a risk of downgrade, then you can even negotiate different versions in a way that can't be detected without access to session keys.

I don't want to have to repeat the ugly hacks we had to add to TLS.  If we can deploy aliasing, I have a little hope that we can use the versionin gmechanism we have designed.

On Wed, Apr 10, 2019, at 18:48, G Fairhurst wrote:
> Obscuring the version of a protocol seems like a major design design 
> decision for wider use cases. So, I'm trying to understand the 
> motivation for version greasing.
> 
> (1) I know there were instances where some early versions of QUIC were 
> blocked due to an uninitentional matching of the header. Is there 
> evidence of intentional attempts to block updates to protocols?
> 
> (2) Thinking about operating a network that cares about user support and 
> protection from unwanted traffic, I would expect that there would be 
> cases where traffic pattern anomolies are found and the appropriate 
> thing would be to try to determine if a new protocol had been deployed 
> and monitor it, if not, then the next most obvious thing could be to 
> block all unexpected traffic, that seems like a decision to hide the 
> version could increase ossification for new versions in these cases.
> 
> (3) Similarly, if a threat is known to impact only a specific (older) 
> version, it would seem to motivate a drop of that traffic that seeks to 
> use that version, while still permitting other traffic. Forcing version 
> detection to use pattern matching/ML will lead to less predictable 
> outcomes, or blocking based on address, etc.
> 
> (4) This obfusticates the most basic piece of reporting information used 
> for support. It hides the extent of deployment of the current protocol 
> version and prevlance of old implementations.
> 
> (5) On the support, if a problem only emerges when a particular version 
> is used with a particular address, then this helps pinpoint the issues. 
> Matching client versions to servers is much more of an issue if the user 
> community uses a wide range of servers (less so, I expect for major 
> providers: google, facebook, etc, etc), but significant when there is a 
> use of a diverse set of external sites and sites with their own load 
> balancers, etc and a need to manage interactions with L2 services.
> 
> I am intersted in knowing if this is likely to benefit or be a new obstacle?
> 
> Gorry
> 
>