Re: [quicwg/base-drafts] Expand AEAD limits to consider multi-user security. (#3789)

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.



> @@ -1552,30 +1549,40 @@ number of attempts to forge packets. TLS achieves this by closing connections
 after any record fails an authentication check. In comparison, QUIC ignores any
 packet that cannot be authenticated, allowing multiple forgery attempts.
 
-Endpoints MUST count the number of received packets that fail authentication for
-each set of keys.  If the number of packets that fail authentication with the
-same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST
-stop using those keys.  Endpoints MUST initiate a key update before reaching
-this limit.  If a key update is not possible, the endpoint MUST immediately
-close the connection.  Applying a limit reduces the probability that an attacker
-is able to successfully forge a packet; see {{AEBounds}} and {{ROBUST}}.
+Endpoints MUST count the number of encrypted packets for each set of keys. If

This is an existing ambiguity.  And the answer is that either endpoint can do the update.  As updates are symmetric, this isn't a big deal, but you can stumble over each other if you do it poorly.

I haven't implemented this bit yet, but when I did it for TLS, the sender updates at limit-N and the receiver requests an update at limit-M where M < N.  This is because the primary responsibility for the update lies with the sender.  This stops endpoints using the same implementation from doing near-simultaneous updates, which is a little wasteful.  If M for one implementation matches N for another, then you can still get a race.  Of course, QUIC handles simultaneous updates well, so maybe you don't care for that level of sophistication.

-- 
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/3789#discussion_r448068353