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

[MikkelFJ <[e-mail]>]

mikkelfj 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.

It is not a man in the middle attack, it is a man on the side attack. The initial packet can be decrypted and a response can be constructed, but at the next encryption level that option is gone. This is why the initial is special. 

If it is possible to forge a reset from the initial packet, something is wrong in the design. It is not possible when a new connection id is produced, but I'm not sure if there the CID is fixed zero length. If there is an attack here, the reset token ought to moved further into the handshake.

-- 
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_r236052984