Re: Questions about Version Negotiation Concerning Possible Handshake Interruption

[Kazuho Oku <[e-mail]>]

2018-02-09 20:19 GMT+09:00 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.

I think that this is a valid concern.

QUIC is tolerant to on-path attackers trying to reset the connection,
once the handshake succeeds. We should spend reasonable effort to
achieve tolerance during the handshake as well.

Regarding how to fix the issue, I think the mitigation that Lingmo
suggested in his first post makes sense (i.e. client waits for some
time even after receiving a VERSION_NEGOTIATION packet).

OTOH, I think that we have room for improving version negotiation. In
TLS, client offers multiple versions and server selects one;
therefore, the handshake finishes in minimal round-trips, which is
good for performance and also gives less chance for on-path attacks to
succeed. In QUIC, the server sends a list of versions and let the
client send another unprotected packet. This is both waste of time and
also is more prone to attacks, due to spending an extra round without
protection.

I think we should change the negotiation scheme so that the server can
select the version to use. The hard part of making such change would
be the fact that we need to decouple the TLS version and the QUIC
version, though.


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



-- 
Kazuho Oku