Re: [quicwg/base-drafts] Define an anti-forgery limit (#3620)

[Jana Iyengar <[e-mail]>]

@janaiyengar commented on this pull request.

This seems good overall, but a few comments

> +Section 5.5 of {{!TLS13}} apply. {{!TLS13}} does not specify a limit for
+AEAD_AES_128_CCM, but the analysis in {{ccm-bounds}} shows that a limit of 2^24
+packets can be used to obtain the same confidentiality protection as the limits
+specified in TLS.
+
+The usage limits defined in TLS 1.3 exist to provide protection against attacks
+on confidentiality and apply to successful applications of AEAD protection. The
+integrity protections in authenticated encryption also depend on limiting the
+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 attempts at defeating
+integrity protection.
+
+Endpoints MUST count the number of packets that are received but cannot be
+authenticated. Packet protection keys MUST NOT be used for removing packet
+protection after authentication fails on more than a per-AEAD limit. Endpoints

What's a "per-AEAD limit"?

> +on confidentiality and apply to successful applications of AEAD protection. The
+integrity protections in authenticated encryption also depend on limiting the
+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 attempts at defeating
+integrity protection.
+
+Endpoints MUST count the number of packets that are received but cannot be
+authenticated. Packet protection keys MUST NOT be used for removing packet
+protection after authentication fails on more than a per-AEAD limit. Endpoints
+MUST initiate a key update before reaching this limit. Applying a limit reduces
+the probability than attacker is able to successfully forge a packet; see
+{{AEBounds}} and {{ROBUST}}.
+
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the
+number of packets that fail authentication MUST NOT exceed 2^36. Note that the

This MUST NOT is a bit of a circuitous requirement. Perhaps "if the number of packets that fail authentication exceeds 2^36, the endpoint MUST immediately close the connection"

> +packet that cannot be authenticated, allowing multiple attempts at defeating
+integrity protection.
+
+Endpoints MUST count the number of packets that are received but cannot be
+authenticated. Packet protection keys MUST NOT be used for removing packet
+protection after authentication fails on more than a per-AEAD limit. Endpoints
+MUST initiate a key update before reaching this limit. Applying a limit reduces
+the probability than attacker is able to successfully forge a packet; see
+{{AEBounds}} and {{ROBUST}}.
+
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the
+number of packets that fail authentication MUST NOT exceed 2^36. Note that the
+analysis in {{AEBounds}} supports a higher limit for the AEAD_AES_128_GCM and
+AEAD_AES_256_GCM, but this specification recommends a lower limit. For
+AEAD_AES_128_CCM the number of packets that fail authentication MUST NOT exceed
+2^24.5; see {{ccm-bounds}}.

similar to above

> +MUST initiate a key update before reaching this limit. Applying a limit reduces
+the probability than attacker is able to successfully forge a packet; see
+{{AEBounds}} and {{ROBUST}}.
+
+For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305 the
+number of packets that fail authentication MUST NOT exceed 2^36. Note that the
+analysis in {{AEBounds}} supports a higher limit for the AEAD_AES_128_GCM and
+AEAD_AES_256_GCM, but this specification recommends a lower limit. For
+AEAD_AES_128_CCM the number of packets that fail authentication MUST NOT exceed
+2^24.5; see {{ccm-bounds}}.
+
+Any TLS cipher suite that is specified for use with QUIC MUST define limits on
+the use of the associated AEAD function that preserves margins for
+confidentiality and integrity. That is, limits MUST be specified for the number
+of packets that can be authenticated and for the number packets that can fail
+authentication.  Any limits SHOULD reference any analysis upon which values are

This is a strange SHOULD. It's a recommendation about how the spec is to be written in the future. I would remove the normative here.

-- 
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/3620#pullrequestreview-407814166