Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption)

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

I was very close to proposing dropping the version negotation packet in
favor of having the client offering multiple versions in the initial
ClientHello. It would also save a roundtrip if negotiating.

However, I realized that it would probably tie the version negotiation to
the TLS handshake which is not a very good idea.

Kind Regards,
Mikkel Fahnøe Jørgensen


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

Hi all

After some discussion with Kazuho and thanks to his help, I want to
propose that for Version Negotiation handling, "a client MAY wait for a
handshake packet after receiving a Version Negotiation packet".

The attack utilizing fake Version Negotiation is too cheap and easy to
be performed (due to no encryption exists) and would be harmful (even
stopping the establishment of connections) so should be mitigated. The
attack that means to make the client abort QUIC connection could be
easily performed with small footprint but also could be mitigated by
simply ignoring those unacceptable Version Negotiation packets in my
rough experiment (if could be called so). Some possible approaches might
be considered:

* A timer could be set after Initial packet sent (might be combined with
one used for re-transmit) for waiting ServerHello. If a Version
Negotiation is received but totally unacceptable, just ignore it. If the
received Version Negotiation is acceptable, it could be considered after
the timeout instead of handled immediately. If a fake packet with
ServerHello received, it should be rejected by TLS so not considered
here.

* When a Version Negotiation is received, instead of handling it within
the same connection, handle it as another connection and remain the
original connection context. If then the ServerHello packet is received,
the new connection context could be dropped and the original connection
would be used following up. This approach might be more difficult to be
implemented than the previous one.

The approaches above are both covered by the statement to be proposed
but not exhaustive. This should be a handling for client side so server
side would have no modification. Due to different implementations of
different clients, it could not be ensure that those approaches are
simple enough to be applied but those malicious Version Negotiation
packets should be properly handled. Also, the scenario where fake
Version Negotiation packets are triggered by each outgoing QUIC
(Initial) packet should also be considered.

For why those Version Negotiation attack would be utilized by malware, I
think they could pretend as server side problem then attract less
attention. If simply dropping packet or faking ICMP host unreachable are
utilized, it would be considered as an issue on route configuration so
more likely a client-side problem thus more attention.

Lingmo Zhu