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

[Watson Ladd <[e-mail]>]

On Fri, Apr 19, 2019 at 7:00 PM Gorry Fairhurst <[e-mail]> wrote:
>
> 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.

The existence of the middlebox is sometimes a testament to the prowess
of the  sales team rather then the engineering team
>
> 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.
> >
>


-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.