Re: How does a server identify a new connection?

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

It ought not be that difficult to race packets. I know someone who measured
a cross Atlantic datacenter to datacenter vs public network to same
location.
It was 30ms faster on the internal network. It might have been RTT in which
case a packet race it is still 15ms faster.

So if you have good connectivity it is viable to race packets over longer
distances.



On 3 December 2018 at 14.56.54, Dmitri Tikhonov ([e-mail])
wrote:

On Mon, Dec 03, 2018 at 01:17:06PM +0900, Kazuho Oku wrote:
> 2018年12月3日(月) 12:14 Dmitri Tikhonov <[e-mail]>:
> > Why is the client struggling? In other words, what attack are we
> > defending against? Is this a real attack -- an adversary racing
> > against the very first client packet -- or a theoretical attack?
>
> I am not sure if the question is good way to consider how QUIC will be
> attacked, because the security properties (and therefore the attack
> vectors) of QUIC is different from that of TCP (that optionally have
> used TLS older than 1.3).

The question is asked in order to understand whether the proposed
defense mechanism is reasonable to implement. The implementation
cost on the server is high given that the attack does not exist.

> Having that said, what we know is that 1) man-on-the-side reset
> injection is a common technique, and 2) it is often coupled with
> packet payload inspection [1].

The reset injection attack described in the referred paper (Section
4.2.3) injects RST packets into an-already established connection.
Both in this and in the Quantum Insert scenarios the injected
packets do not have to race the legitimate packet(s) that were used
to construct them. This seems like an impossible problem for the
man-on-the-side to solve.

> With TLS 1.3, the only remaining way for a middlebox to inspect the
> payload of a packet in practice is to look at the SNI of the
> ClientHello. With QUIC, injection during the exchange of Initial
> packets would be the only way for a man-on-the-side attacker to
> disrupt the connection (assuming that we address the issue with
> spoofing path challenges / responses).
>
> Considering that, I would assume that racing a spoofed Initial to the
> server will be one of the vectors to be considered by the attackers,
> and therefore it's worth considering, documenting and encouraging
> implementations to have the countermeasures.

I agree that it's worth considering. I have been wanting to see how
this vector could be used for an attack by the man-on-the-side, but
no explanation has been put forth so far.

- Dmitri.

> [1] https://tools.ietf.org/html/draft-hall-censorship-tech-06