Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

[Christian Huitema <[e-mail]>]

I am trying to wrap my head around the "transport parameters" proposal. I am looking at the sequence of the attack:

1) Client sends an Initial packet with a specific DCID (later referred to as ODCID)
2) Server sends a retry packet in which the DCID copies the original SCID of the client, and the SCID is set to the value that the server wants the client to use as the next DCID -- calling this Retry-CID
3) Attacker intercepts the retry packet, replaces the DCID by A-CID.
4) Client starts a new connection with DCID = A-CID instead of the expected Retry-CID, which possibly opens the possibility of attacks against the server, such as paying games with the load balancer.
5) Client includes some new transport parameters in Initial packets
6) Attacker possibly intercepts the client packet and messes with the transport parameters.

At that point, we have different outcomes based on the defenses implemented by the server:

a) If the server has tied the Retry-CID and the ODCID to the token, the server finds that the incoming client Initial does not meet expectations, and closes the connection with an adequate error code.

b) If the server did not do (a), the server will start establishing the connection, sending the server transport parameters as part of the encrypted extensions, in Handshake packets. The transport parameters include the ODCID. If I understand the proposal correctly, the transport parameters would also include the Retry-CID. The client would then receive these parameters, find out that something is amiss, and close the connection.

Given these two choices, it seems that option (a) is much better. The Retry mechanism is designed for use under attack. In these scenarios, it is important to minimize the amount of work at the server. If the server has tied Retry-CID to the token, the session is terminated upon the first initial packet, which seems like the desired result. If not doing that, the server will expand resource to compute session keys, signatures, etc., which means that the DOS attack is more effective.

I also think that the server should not rely on the client for protection. The ODCID transport parameter and the proposed Retry-CID parameter allow the client to verify that things are as expected. But suppose for a moment that the attacker is the client itself, and that the goal of the attack is to overwhelm a specific server in the farm by using well chosen DCID. The "attacker-client" will certainly not terminate the connection on Retry-CID mismatch!

Then, I also wonder how servers would implement the Retry-CID transport parameter. It seems that currently many servers implement the ODCID requirement by encoding the ODCID in the token. I assume that server will implement the Retry-CID either by using algorithmic derivation of Retry-CID from ODCID, or by adding the Retry-CID to the token. In both cases, they can implement option (a). 

So in practice, there is little incremental work for a server if it wants to do (a) rather than (b), and there are sizable benefits in terms of reduced DoS surface. The recommendation ought to be, do (a). Now, if servers actually do (a), they will have no problem also sending a Retry-CID transport parameter in the "all clear" case. But that will not be very useful.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3439#issuecomment-595460613