Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

[Lingmo Zhu <[e-mail]>]

Thank you for the clarification. I admit that downgrade attack could be 
hard to imagine. In fact what I really concerned is some scenario like:

The client accepts version set X and the server cluster accepts some 
versions in X, so handshake should go well. But middle box tries to send 
VNEG with a version list excluding X. If VNEG wins, handshake could be 
aborted.

In that scenario, HTTP could fall back to TCP and be interrupted simply 
by RST. TBH I just hope QUIC could not be easily interrupted. I'm not 
sure if such corner case should be considered.


On 2018/02/09 18:22, Mikkel Fahnøe Jørgensen wrote:
> A possible attack scenario:
>
> A server cluster accepts version X and version Y, and sends {X, Y} in 
> VNEG message if it sees any other requested version.
> Except: the cluster also accepts version X_old to deal with hard to 
> upgrade baby alarms. It never announces X_old in VNEG but it will 
> accept it if proposed by the client.
>
> Middleware now tries to inject X_old in version negotiation to 
> convince the client to use that version in instead of version X the 
> client would normally use. If VNEG wins the handshake race, X_old is 
> now triggered.
>
> But the cluster knows that it would never have proposed X_old so if 
> the client does verify properly, the handshake should fail.
>
> What I’m not sure about is if the current logic actually supports a 
> case were X_old is accepted if volunteered, but never when negotiated.
>
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> On 9 February 2018 at 11.11.13, Martin Thomson 
> ([e-mail] <mailto:[e-mail]>) wrote:
>
>> Any spoofed version negotiation packet will be detected once the
>> handshake completes: the server is required to include its list of
>> supported versions in the TLS handshake. See the link Mikkel provided
>> for details.
>>
>> On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>> > Hi
>> >
>> > I'm new to QUIC and not sure if that could be considered but for 
>> Version
>> > Negotiation with the same connection ID as Initial packet, client 
>> should
>> > choose an acceptable version from the list. What if spoofing from 
>> something
>> > like router happens? Should mitigations be considered, such as 
>> adding a
>> > delay for validated Version Negotiation handling so that following 
>> handshake
>> > packets could be received later and that fake Version Negotiation 
>> could be
>> > ignored?
>> >
>> > Such concerning is just come out from DNS hijacking which is partially
>> > similar, though for QUIC it would only interrupt the handshake. I'm 
>> not sure
>> > but it might be used by downgrade attack in the future. Of course 
>> I'm new to
>> > this field so my opinion would be wrong.
>> >
>> > Thanks.
>> >
>> > Lingmo Zhu
>> >
>>