Draft: draft-ietf-tls-dtls13

Commentary: 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  is a while different story . As that is defined in TLS 1.3 , it seems necessary to address it here . QUIC simply does n'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 can not 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 for a more thorough description of the problem and the analysis of different options .
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.