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

[Christian Huitema <[e-mail]>]

On 2/19/2018 5:26 AM, Lubashev, Igor wrote:

> For clients that have a tcp fallback, this kind of an attack
> mitigation would need to be done together with some happy eyeballs
> race. Otherwise, waiting for a timeout on VN has a real performance
> cost to the user in case there is no attack happening. So if this kind
> of an artificial delay in VN is mentioned, starting the fallback would
> need to be mentioned as well. All this seems like it could belong to
> an optimization/applicability/happy-eyeballs-for-QUIC draft, if it
> belongs anywhere at all, but not the transport draft.

That's reasonable. Several people have expressed concerns about
man-on-the-side attacks. We have heard various proposals for hardening
the initial handshake. The typical concern is an adversary "that taps
optic fiber at an internet distribution node", to use Mikkel's words,
although we may also be concerned by an on-link attacker in an Ethernet
or Wi-Fi network. The adversary gets a copy of packets, parses them, and
finds a pattern that triggers an attack. The adversary then sends a
forged packet to one end of the connection or another, with a goal of
causing either a connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending
a forged version negotiation packet. I think that's a valid concern, but
only one of many. We should be equally concerned with forged stateless
reset packets, or forged handshake packets: anything that happens before
protection is negotiated can be forged.  I would support writing a draft
that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--