Draft: draft-ietf-tls-dtls13

Commentary: Yet another attempt to This builds on  's PR but just omits the epoch entirely from the AEAD nonce calculation . This is more consistent with TLS and does n't require special case reasoning about why we only need to build in the bottom 16 bits . This relies entirely on the keys being different . Needs analysis . 
 This seems promising . 
 this LGTM , but there 's a conflict . Can you resolve prior to merging ? are you OK with the new rationale , and text that allows it to be relaxed in the future ? 
 If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES - GCM connection to 2 ^ 40.5 compared to 2 ^ 64 in DTLS 1.2 . This is quite a severe limitation that is not mentioned explicitly . The AEAD limits in themselves are not a problem , but the combination of AEAD limits ( 2 ^ 24.5 ) and a small epoch ( 2 ^ 16 ) is a problem . I think this is major problem in some use cases of DTLS . E.g. most 3GPP 5 G use cases where DTLS or DTLS / SCTP is used for semi - permanent connections ( lasting years ) and where the terminating the connection cause severe disturbances . I did not find any discussion about this problem ( but I could easily have missed it ) It is known that the limit of 2 ^ 48 packets in SRTP can be reached and 2 ^ 40.5 is significantly smaller than this ... If the document was not in such a late stage , I would have suggested to increase the size of the epoch to 32 bits ..... I think this and the other problems DTLS 1.3 has with semi - permanent connections has to be solved sooner than later . 
 thanks for filing this . I hear you about the late stage , but IIRC we never represent the entire epoch on the wire in any case , so it seems like just changing it to 32 bits would be pretty easy , so why not do it now ? 
 How do the chacha20 numbers compare to the AES - GCM ones ? 
 I do n't think ( D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2 ^ 64 ( 2 ^ 48 2 ^ 16 ) AES - GCM 2 ^ 40.5 ( 2 ^ 24.5 2 ^ 16 ) AES - GCM 2 ^ 39 ( 2 ^ 23 * 2 ^ 16 ) 
 I am all for changing this now . I made a PR that change epoch from uint16 to uint32 . As you say , it seems like a pretty easy change to do . Is uint32 the right size ? 
 Unless you think we should do  . what would we have to do to make this change ? 
 Magnus Westerlund thinks  would be a safer bet .   suggest to wrap the uint16 epoch instead . That might be an easier solution . I do n't see a direct problem in DTLSPlaintext , ACK message , or recordsequencenumber with a uint16 epoch that is allowed to wrap like : 4 , 5 , ... 2 ^ 16 - 1 , 4 , 5 , ... 2 ^ 16 - 1 , 4 , 5 , ... 
 since it 's through the IESG we would need to at least raise that this change was made after they had approved it . I suspect that doing some kind of 2 - week heads up to the WG / IESG that we want to make the change before landing it . But , if we do that or something more drastic that 's really up to 
 I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that does n't wrap , and then to ensure that one does n't practically run into any limits , then an  would be better . An unit32 appears to be sufficient for a quite extreme use case with minimal messages size ( which is one DTLS record with 4 byte user message ) and high bandwidth ( 10 Gbps ) sustained over a period of more than 5 years before the epoch would wrap . However , to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4 - bytes to be certain to have eliminated any practical limitation . 
 I think a 2 - week WGLC and notifying the IESG will suffice . 
 FYI . We have now run into quite many problems with the interworking of semi - permanent DTLS / SCTP connections ( lasting years ) and DTLS 1.3 : No Diffie - Hellman rekeying No post - handshake server authentication No rekeying of the exporter_secret 2 ^ 40.5 packets limit 2 minute MSL requirement 2 ^ 38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3 , leave DTLS / SCTP as is , but as the problems keep adding up we are now startnig to consider quite big changes to DTLS / SCTP 1.3 to make this work : Using new DTLS connections instead of KeyUpdate could potentially address the first five , but is a significant change . 
 Hi , Based on the problems long - lived DTLS / SCTP had with DTLS 1.3 ( as well as DTLS 1.2 without renegotiation and respecting AEAD limits ) we restructured DTLS / SCTP ( RFC6083bis ) to use parallel connections instead of relying on renegotiation and post - handshake messages . We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3 . It also makes DTLS / SCTP less dependant on version specific DTLS mechanisms . It will hopefully work without changes with any future DTLS 1.4 . We can now firmly RECOMMEND DTLS 1.3 which I think is very important . 5 G is to a large degree replacing or complementing IPsec with TLS , DTLS , and DTLS / SCTP . I will do my best to transition 3GPP to DTLS 1.3 asap . FYI , 3GPP DTLS / SCTP associations have very long lifetimes ( can be years ) , strive for five nines ( 99.999 % ) availability and can not be teared down without causing major disruptions . With such long lifetimes we think mutual reauthentication , rekeying of the SCTP - AUTH key , and forcing attackers to dynamic key exfiltration [ RFC7624 ] are required features . I still think should be done . 2 ^ 40.5 packets is quite limiting . 
 Seems OK.Thanks -- this LGTM . We 'll need to do a brief consensus call given the type of change .
Paragraph (version B):
The DTLS epoch serialized in DTLSPlaintext is 2 octets long for
compatibility with DTLS 1.2.  However, this value is set as the
least significant 2 octets of the connection epoch, which is an 8
octet counter incremented on every KeyUpdate.  See seq-and-epoch
for details.  The sequence number is set to be the low order 48
bits of the 64 bit sequence number.  Plaintext records MUST NOT be
sent with sequence numbers that would exceed 2^48-1, so the upper
16 bits will always be 0.
Paragraph (version B):
The least significant 2 bytes of the connection epoch value.
Paragraph (version A):
This 64-bit value is used in the ACK message as well as in the
"record_sequence_number" input to the AEAD function.
Paragraph (version A):
The entire header value shown in hdr_examples (but prior to record
number encryption, see rne) is used as as the additional data value
for the AEAD function.  For instance, if the minimal variant is used,
the AAD is 2 octets long.  Note that this design is different from
the additional data calculation for DTLS 1.2 and for DTLS 1.2 with
Connection ID.
Paragraph (version B):
This 128-bit value is used in the ACK message.
Paragraph (version B):
The entire header value shown in hdr_examples (but prior to record
number encryption, see rne) is used as as the additional data value
for the AEAD function.  For instance, if the minimal variant is used,
the AAD is 2 octets long.  Note that this design is different from
the additional data calculation for DTLS 1.2 and for DTLS 1.2 with
Connection ID.  In DTLS 1.3 the 64-bit sequence_number is used as the
sequence number for the AEAD computation; unlike DTLS 1.2, the epoch
is not included.
Paragraph (version A):
Implementations MUST NOT allow the epoch to wrap, but instead MUST
establish a new association, terminating the old association.
Paragraph (version B):
When receiving protected DTLS records, the recipient does not have a
full epoch or sequence number value in the record and so there is
some opportunity for ambiguity.  Because the full sequence number is
used to compute the per-record nonce and the epoch determines the
keys, failure to reconstruct these values leads to failure to
deprotect the record, and so implementations MAY use a mechanism of
their choice to determine the full values.  This section provides an
algorithm which is comparatively simple and which implementations are
RECOMMENDED to follow.
Paragraph (version A):
epoch value (4 to 2^16-1) is used for payloads protected using
keys from the [sender]_application_traffic_secret_N (N>0).
Paragraph (version B):
epoch value (4 to 2^64-1) is used for payloads protected using
keys from the [sender]_application_traffic_secret_N (N>0).
Paragraph (version B):
With a 128-bit key as in AES-256, rekeying 2^64 times has a high
probability of key reuse within a given connection.  Note that even
if the key repeats, the IV is also independently generated.  In order
to provide an extra margin of security, sending implementations MUST
NOT allow the epoch to exceed 2^48-1.  In order to allow this value
to be changed later, receiving implementations MUST NOT enforce this
rule.  If a sending implementation receives a KeyUpdate with
request_update set to "update_requested", it MUST NOT send its own
KeyUpdate if that would cause it to exceed these limits.