Re: How does a server identify a new connection?

[Kazuho Oku <[e-mail]>]

I've submitted a PR that implements the proposed approach.

https://github.com/quicwg/base-drafts/pull/2076
2018年11月29日(木) 11:30 Kazuho Oku <[e-mail]>:
>
> So far, we have been trying to spend reasonable effort to prevent
> man-on-the-side attacks.
>
> Specifically, PR #2045 (Discard Initial keys as soon as possible) is
> an attempt to prevent that during the handshake.
>
> Assuming that we adopt the PR, client's complexity of avoiding a
> man-on-the-side attack becomes O(M*N) where M is the number of
> server's Initial packets (assuming that ServerHello fits in one packet
> and HRR is not involved) and N is the number of packets being received
> [1].
>
> However, there still exists an attack vector. The attacker can target
> the server instead, racing an Initial packet. If the attacker's
> Initial (that contain a different ClientHello) reaches the server
> before the one sent by the client, the TLS handshake would fail,
> assuming that the server considers those two Initial packets to be
> belonging to the same connection.
>
> The question is if (and how) we can prevent that from happening.
>
> One way that might work is to use H(SCIDL || DCIDL || SCID || DCID ||
> ClientHello) of the Initial packet where H is a cryptographic hash
> function to identify each connection establishment attempt. In
> practice, a server would remember this value for each connection, and
> if the value differs from a known value, creates a new connection
> context and responds with an Initial that contains a new Server CID
> (even if the 5-tuple and Client's CID is identical to an existing
> connection).
>
> Does this sound sufficient to avoid the man-on-the-side attack
> targeting the server racing Initial packets? Is there a better way?
> Should we describe this type of construction in the drafts?
>
>
> [1] https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit
> section 3.4
>
> --
> Kazuho Oku



-- 
Kazuho Oku