Change:
because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer. <ins> 4.5.3. Section 5.5 of TLS TLS13 defines limits on the number of records that can be protected using the same keys.  These limits are specific to an AEAD algorithm, and apply equally to DTLS.  Implementations SHOULD NOT protect more records than allowed by the limit specified for the negotiated AEAD.  Implementations SHOULD initiate a key update before reaching this limit. 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, DTLS ignores any packet that cannot be authenticated, allowing multiple forgery attempts. Implementations MUST count the number of received packets that fail authentication with each key.  If the number of packets that fail authentication exceed a limit that is specific to the AEAD in use, an implementation SHOULD immediately close the connection. Implementations SHOULD initiate a key update with update_requested before reaching this limit.  Once a key update has been initiated, the previous keys can be dropped when the limit is reached rather than closing the connection.  Applying a limit reduces the probability that an 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 limit on the number of records 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 records that fail authentication is 2^23.5; see ccm-bounds. The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_SHA256, does not have a limit on the number of records that fail authentication that both limits the probability of forgery by the same amount and does not expose implementations to the risk of denial of service; see ccm-short.  Therefore, TLS_AES_128_CCM_SHA256 MUST NOT used in DTLS without additional safeguards against forgery.  Implementations MUST set usage limits for AEAD_AES_128_CCM_8 based on an understanding of any additional forgery protections that are used. Any TLS cipher suite that is specified for use with DTLS MUST define limits on the use of the associated AEAD function that preserves margins for both 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> 5. DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the

Discussion:
And define limits for the CCM ciphers. This turned out to be a little tricky. I copied the text about AEADAES128CCM from the QUIC PR, which is easy, but AEADAES128CCM8 is a while different story. As that is defined in TLS 1.3, it seems necessary to address it here. QUIC simply doesn't allow that, but I assume that DTLS will. On the basis that DTLS will allow AEADAES128CCM_8, we need some language about it. I've tried to write something, but I'm not very happy with it. I'd greatly prefer not to allow this AEAD in DTLS. It's basically fine in TLS, but here the margins are just too narrow. I realize that 2^-57 is essentially arbitrary, you might reasonably say that 2^-40 is better, but that would change the analysis in other ways.
We cannot get rid of CCM_8 because this is used in various IoT standards and it is also implemented in hardware.
That's why this PR is shaped as it is. Some of us which we could get rid of it though; it's just not strong enough.
We should count failed "deprotection" attempts and limit the number that are permitted with any given key. Otherwise, an attacker might be able to successfully forge a record. See URL for a more thorough description of the problem and the analysis of different options.