Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

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

For the TCP fallback case, this is higher level protocol specific. For
HTTP/QUIC v1 I believe there is a requirement to not fall back to anything
there is a requirement to below TLS 1.3.

But it is a valid concern.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 9 February 2018 at 12.19.50, Lingmo Zhu ([e-mail]) wrote:

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