Re: [quicwg/base-drafts] Discard Initial keys as soon as possible (#2045)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.



> @@ -691,6 +692,24 @@ will be marked as lost before this, as they leave a gap in the sequence of
 packet numbers.
 
 
+## Discarding Initial Keys {#discard-initial}
+
+Packets protected with Initial secrets ({{initial-secrets}}) are not
+authenticated, meaning that an attacker could spoof packets with the intent to
+disrupt a connection.  To limit these attacks, Initial packet protection keys
+can be discarded more aggressively than other keys.
+
+The successful use of Handshake packets indicates that no more Initial packets
+need to be exchanged, as these keys can only be produced after receiving all
+CRYPTO frames from Initial packets.  Thus, a client MUST discard Initial keys
+when it first sends a Handshake packet and a server MUST discard Initial keys
+when it first successfully processes a Handshake packet.  Endpoints MUST NOT
+send Initial packets after this point.

I agree with the spirit of the text: we must defend against this attack, and the proper way has to be some form of implicit ACK. But I would like to see the implicit acknowledgement mechanism specified in the transport draft, because it affects the transport state machine. Obviously, bad things would happen if one side decided to stop send sending Initial packets while the other side was still waiting for ACK of its own packets, and repeating them. That means we must be crystal clear on when exactly to perform this "initial cut-off": on the client side, when the Handshake secret is successfully received and the client starts being able receiving handshake packets; on the server side, when the first handshake packet is received from the server.

> @@ -691,6 +692,24 @@ will be marked as lost before this, as they leave a gap in the sequence of
 packet numbers.
 
 
+## Discarding Initial Keys {#discard-initial}
+
+Packets protected with Initial secrets ({{initial-secrets}}) are not
+authenticated, meaning that an attacker could spoof packets with the intent to
+disrupt a connection.  To limit these attacks, Initial packet protection keys
+can be discarded more aggressively than other keys.
+
+The successful use of Handshake packets indicates that no more Initial packets
+need to be exchanged, as these keys can only be produced after receiving all
+CRYPTO frames from Initial packets.  Thus, a client MUST discard Initial keys
+when it first sends a Handshake packet and a server MUST discard Initial keys
+when it first successfully processes a Handshake packet.  Endpoints MUST NOT
+send Initial packets after this point.

I also looked at how to implement a similar protection without this kind of cut-off, and it just does not work. Suppose for example that the client receives a repeated Initial packet after the cut-off. In the post cutoff defensive mode, it can decide to ignore the packet content, since it cannot possibly learn anything interesting, but it would still need to send an ACK, otherwise the peer will keep repeating 3 or 4 times and then give up on the connection. But then, if the packet from the "server" was forged, the ACK from the client will be treated as a protocol violation, and the server will close the connection. Catch 22, no good way to get out of that.

-- 
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/pull/2045#discussion_r236126691