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

[Gorry Fairhurst <[e-mail]>]

So... to check I understand that argument, it seems that some people 
expecs to see deployment of middleboxes that intercept QUIC - is that right?

- if the middlebox doesn't exist, because it can't usefully add value, 
the version number does not need to be encrypted.
- but if there are incentives to deploy middleboxes to do something 
(what?) then I could seee there could be a concern that these boxes 
could be implemented in a way that the implementers make them dependent 
on the version of QUIC.

Gorry

The first step is the part I don't understand, with TLS/TCP I understand 
the use-case existed.

On 19/04/2019, 23:48, Martin Duke wrote:
> Right. This is the exact use case that version greasing is supposed to 
> avoid; i.e. a nontrivial amount of QUIC traffic greases, so 
> middleboxes that do this kind of thing impose unacceptable performance 
> penalties on users and don't make their way into the network.
>
> On Fri, Apr 19, 2019 at 12:59 PM Salz, Rich <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     *>*Can Brian (or anyone else) comment on what the threat model was
>     that caused middleboxes to drop TLS 1.3 when it used the actual
>     version field?
>
>     “safety”
>
>     Less flippantly, they didn’t understand the new version so they
>     could not be sure it was okay to pass through, they didn’t know
>     how to do content inspection, TLS offload, etc.
>