Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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])
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]> 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
>