Code change:
Key updates MUST be initiated before usage limits on packet protection keys are exceeded.  For the cipher suites mentioned in <del> this document, the limits in Section 5.5 of TLS13 apply.  Other cipher suites MUST define usage limits in order to be used with QUIC. </del> <ins> this document, the limits in 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^23 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 for 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 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. Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 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 limit on the number of packets that fail authentication is 2^23.5; see ccm-bounds. These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. 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.  Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. </ins> 6.7.

Related discussion:
text: To keep the advantage an attacker has to 2^-60 (to match the analysis in TLS), we therefore need to keep q to below 2^24.5. Somewhat unsurprisingly, that matches the numbers we have for AES-GCM. Jonsson puts the advantage for an attacker over a generic PRF at . As the first term is negligible even for large v (up to 2^64), we consider the second term alone and aim for a bound on the advantage of 2^-57 to match the analysis for other ciphers. That leaves us with . As q is already established to be 2^24.5, we can say that v should be limited to 2^25 (or if you want to be precise). (As a side note, for t=64, as in AEADAES128CCM8, the first term becomes relevant and our security bound limits the number of forgeries to 2^7, which is probably a bit limiting in practice. That's good justification for not enabling AEADAES128CCM_8 by default; though different applications might use a different target bound than 2^-57.) I'm an not a cryptographer. These papers all read like chicken-chicken-chicken. My calculations are not infallible either.
The shape of the bound seems plausible but I'll start a thread with the cryptographers to check everything
I reproduced Martin's analysis of CCM based on of the bounds by . (Myself not being an expert in producing such bounds, I found the second-level confirmation by Rogaway to be helpful.) I essentially agree with the numbers, except that --when following the same metric as the -- the advantage over an ideal PRP (instead of PRF) should be considered. This simply means losing a 1/2 factor in the bound: Confidentiality bound: yields an advantage of . I'd hence say it's fine to keep TLS 1.3's recommendation on sending max. full-sized records. Integrity bound: , hence yields an advantage of (matching the other analyses). Most importantly, I concur with Martin that AEADAES128CCM8 would need either much lower bounds or a different risk assessment: applying the same limit of would bring the advantage incurred through the bound up to .