client:

The endpoint initiating the DTLS connection.

association:

Shared state between two endpoints established witha DTLS handshake.

connection:

Synonym for association.

endpoint:

Either the client or server of the connection.

epoch:

One set of cryptographic keys used for encryption and decryption.

handshake:

An initial negotiation between client and server that establishesthe parameters of the connection.

peer:

An endpoint. When discussing a particular endpoint, "peer" refers tothe endpoint that is remote to the primary subject of discussion.

receiver:

An endpoint that is receiving records.

sender:

An endpoint that is transmitting records.

server:

The endpoint that did not initiate the DTLS connection.

CID:

Connection ID.

MSL:

Maximum Segment Lifetime.

'+'

indicates noteworthy extensions sent in the previously noted message.

'*'

indicates optional or situation-dependent messages/extensions that are not always sent.

'{}'

indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.

'[]'

indicates messages protected using keys derived from traffic_secret_N.

1. TLS relies on an implicit sequence number on records. If a record is not received, then the recipient will use the wrong sequence number when attempting to remove record protection from subsequent records. DTLS solves this problem by adding sequence numbers to records.
2. The TLS handshake is a lock-step cryptographic protocol. Messages must be transmitted and received in a defined order; any other order is an error. The DTLS handshake includes message sequence numbers to enable fragmented message reassembly and in-order delivery in case datagrams are lost or reordered.
3. Handshake messages are potentially larger than can be contained in a single datagram. DTLS adds fields to handshake messages to support fragmentation and reassembly.
4. Datagram transport protocols are susceptible to abusive behavior effecting denial-of-service (DoS) attacks against nonparticipants. DTLS adds a return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 for details).

1. The DTLSCiphertext structure omits the superfluous version number and type fields.
2. DTLS adds an epoch and sequence number to the TLS record header. This sequence number allows the recipient to correctly decrypt and verify DTLS records. However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure has been reduced from those in previous versions.
3. 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 Section 4.2 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.
4. The DTLSCiphertext structure has a variable-length header.

    struct {
        ContentType type;
        ProtocolVersion legacy_record_version;
        uint16 epoch = 0
        uint48 sequence_number;
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
    } DTLSPlaintext;

    struct {
         opaque content[DTLSPlaintext.length];
         ContentType type;
         uint8 zeros[length_of_padding];
    } DTLSInnerPlaintext;

    struct {
        opaque unified_hdr[variable];
        opaque encrypted_record[length];
    } DTLSCiphertext;

legacy_record_version:

This value MUST be set to {254, 253} for all records otherthan the initial ClientHello (i.e., one not generated after a HelloRetryRequest),where it may also be {254, 255} for compatibility purposes. It MUST be ignored for all purposes. See [TLS13], Appendix D.1 for the rationale for this.

epoch:

The least significant 2 bytes of the connection epoch value.

unified_hdr:

The unified header (unified_hdr) is a structure of variable length, shown in Figure 3.

encrypted_record:

The encrypted form of the serialized DTLSInnerPlaintext structure.

    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|0|1|C|S|L|E E|
    +-+-+-+-+-+-+-+-+
    | Connection ID |   Legend:
    | (if any,      |
    /  length as    /   C   - Connection ID (CID) present
    |  negotiated)  |   S   - Sequence number length
    +-+-+-+-+-+-+-+-+   L   - Length present
    |  8 or 16 bit  |   E   - Epoch
    |Sequence Number|
    +-+-+-+-+-+-+-+-+
    | 16 bit Length |
    | (if present)  |
    +-+-+-+-+-+-+-+-+

Fixed Bits:

The three high bits of the first byte of the unified header are set to001. This ensures that the value will fit within the DTLS region whenmultiplexing is performed as described in [RFC 7983]. It also ensuresthat distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2records is possible when they are carried on the same host/port quartet;such multiplexing is only possible when CIDs [RFC 9146]are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).

C:

The C bit (0x10) is set if the Connection ID is present.

S:

The S bit (0x08) indicates the size of the sequence number.0 means an 8-bit sequence number, 1 means 16-bit. Implementations MAY mix sequence numbers of different lengths on the same connection.

L:

The L bit (0x04) is set if the length is present.

E:

The two low bits (0x03) include the low-order two bits of the epoch.

Connection ID:

Variable-length CID. The CID functionalityis described in [RFC 9146]. An examplecan be found in Section 9.1.

Sequence Number:

The low-order 8 or 16 bits of the record sequence number. This value is 16bits if the S bit is set to 1, and 8 bits if the S bit is 0.

Length:

Identical to the length field in a TLS 1.3 record.

 0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
| Content Type  |     |0|0|1|1|1|1|E E|     |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|   16 bit      |     |               |     |8 bit Seq. No. |
|   Version     |     / Connection ID /     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+     |               |     |               |
|   16 bit      |     +-+-+-+-+-+-+-+-+     |   Encrypted   |
|    Epoch      |     |    16 bit     |     /   Record      /
+-+-+-+-+-+-+-+-+     |Sequence Number|     |               |
|               |     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|               |     |   16 bit      |
|   48 bit      |     |   Length      |       DTLSCiphertext
|Sequence Number|     +-+-+-+-+-+-+-+-+         Structure
|               |     |               |         (minimal)
|               |     |  Encrypted    |
+-+-+-+-+-+-+-+-+     /  Record       /
|    16 bit     |     |               |
|    Length     |     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|               |      DTLSCiphertext
|               |        Structure
/   Fragment    /          (full)
|               |
+-+-+-+-+-+-+-+-+

 DTLSPlaintext
   Structure

    struct {
        uint64 epoch;
        uint64 sequence_number;
    } RecordNumber;

• If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record.
• If the first byte is any other value, then receivers MUST check to see if the leading bits of the first byte are 001. If so, the implementation MUST process the record as DTLSCiphertext; the true content type will be inside the protected portion.
• Otherwise, the record MUST be rejected as if it had failed deprotection, as described in Section 4.5.2.

             +----------------+
             | Outer Content  |
             |   Type (OCT)   |
             |                |
             |   OCT == 20   -+--> ChangeCipherSpec (DTLS <1.3)
             |   OCT == 21   -+--> Alert (Plaintext)
             |   OCT == 22   -+--> DTLSHandshake (Plaintext)
             |   OCT == 23   -+--> Application Data (DTLS <1.3)
             |   OCT == 24   -+--> Heartbeat (DTLS <1.3)
packet  -->  |   OCT == 25   -+--> DTLSCiphertext with CID (DTLS 1.2)
             |   OCT == 26   -+--> ACK (DTLS 1.3, Plaintext)
             |                |
             |                |   /+----------------+\
             | 31 < OCT < 64 -+--> |DTLSCiphertext  |
             |                |    |(header bits    |
             |      else      |    | start with 001)|
             |       |        |   /+-------+--------+\
             +-------+--------+            |
                     |                     |
                     v          Decryption |
               +---------+          +------+
               |  Reject |          |
               +---------+          v
                            +----------------+
                            | Decrypted      |
                            | Content Type   |
                            | (DCT)          |
                            |                |
                            |     DCT == 21 -+--> Alert
                            |     DCT == 22 -+--> DTLSHandshake
                            |     DCT == 23 -+--> Application Data
                            |     DCT == 24 -+--> Heartbeat
                            |     DCT == 26 -+--> ACK
                            |     else ------+--> Error
                            +----------------+

• The DTLS record framing expands the datagram size, thus lowering the effective PMTU from the application's perspective.
• In some implementations, the application may not directly talk to the network, in which case the DTLS stack may absorb ICMP "Datagram Too Big" indications [RFC 1191] or ICMPv6 "Packet Too Big" indications [RFC 4443].
• The DTLS handshake messages can exceed the PMTU.

• For DTLS over UDP, the upper layer protocol SHOULD be allowed to obtain the PMTU estimate maintained in the IP layer.
• For DTLS over DCCP, the upper layer protocol SHOULD be allowed to obtain the current estimate of the PMTU.
• For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there is no PMTU limitation. However, the upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes.

• Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the Don't Fragment (DF) bit (in IPv4) or prohibit local fragmentation (in IPv6).
• If the underlying transport protocol allows the application to request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD honor this request.

• If the DTLS record layer informs the DTLS handshake layer that a message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU.
• If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a smaller record size, fragmenting the handshake message as appropriate. This specification does not specify an exact number of retransmits to attempt before backing off, but 2-3 seems appropriate.

1. To handle message loss, reordering, and fragmentation, modifications to the handshake header are necessary.
2. Retransmission timers are introduced to handle message loss.
3. A new ACK content type has been added for reliable message delivery of handshake messages.

1. An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
2. An attacker can use the server as an amplifier by sending connection initiation messages with a forged source address that belongs to a victim. The server then sends its response to the victim machine, thus flooding it. Depending on the selected parameters, this response message can be quite large, as is the case for a Certificate message.

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloRetryRequest
                                    + cookie

      ClientHello           ------>
       + cookie

      [Rest of handshake]

    uint16 ProtocolVersion;
    opaque Random[32];

    uint8 CipherSuite[2];    /* Cryptographic suite selector */

    struct {
        ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
        Random random;
        opaque legacy_session_id<0..32>;
        opaque legacy_cookie<0..2^8-1>;                  // DTLS
        CipherSuite cipher_suites<2..2^16-2>;
        opaque legacy_compression_methods<1..2^8-1>;
        Extension extensions<8..2^16-1>;
    } ClientHello;

legacy_version:

In previous versions of DTLS, this field was used for versionnegotiation and represented the highest version number supported bythe client. Experience has shown that many servers do not properlyimplement version negotiation, leading to "version intolerance" inwhich the server rejects an otherwise acceptable ClientHello with aversion number higher than it supports. In DTLS 1.3, the clientindicates its version preferences in the "supported_versions"extension (see Section 4.2.1 of [TLS13]) and thelegacy_version field MUST be set to {254, 253}, which was the versionnumber for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 are0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is usedto indicate DTLS 1.3.

random:

Same as for TLS 1.3, except that the downgrade sentinels describedin Section 4.1.3 of [TLS13] when TLS 1.2and TLS 1.1 and below are negotiated apply to DTLS 1.2 and DTLS 1.0, respectively.

legacy_session_id:

Versions of TLS and DTLS before version 1.3 supported a "session resumption"feature, which has been merged with pre-shared keys (PSK) in version 1.3. A clientwhich has a cached session ID set by a pre-DTLS 1.3 server SHOULD set thisfield to that value. Otherwise, it MUST be set as a zero-length vector(i.e., a zero-valued single byte length field).

legacy_cookie:

A DTLS 1.3-only client MUST set the legacy_cookie field to zero length.If a DTLS 1.3 ClientHello is received with any other value in this field,the server MUST abort the handshake with an "illegal_parameter" alert.

cipher_suites:

Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.

legacy_compression_methods:

Same as for TLS 1.3.

extensions:

Same as for TLS 1.3.

• Table 1 does not highlight any of the optional messages.
• Regarding note (1): When a handshake flight is sent without any expected response, as is the case with the client's final flight or with the NewSessionTicket message, the flight must be acknowledged with an ACK message.

Client                                            Server

                                                           +--------+
 ClientHello                                               | Flight |
                       -------->                           +--------+

                                                           +--------+
                       <--------        HelloRetryRequest  | Flight |
                                         + cookie          +--------+


                                                           +--------+
ClientHello                                                | Flight |
 + cookie              -------->                           +--------+



                                              ServerHello
                                    {EncryptedExtensions}  +--------+
                                    {CertificateRequest*}  | Flight |
                                           {Certificate*}  +--------+
                                     {CertificateVerify*}
                                               {Finished}
                       <--------      [Application Data*]



 {Certificate*}                                            +--------+
 {CertificateVerify*}                                      | Flight |
 {Finished}            -------->                           +--------+
 [Application Data]
                                                           +--------+
                       <--------                    [ACK]  | Flight |
                                      [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]

 ClientHello                                              +--------+
  + pre_shared_key                                        | Flight |
  + psk_key_exchange_modes                                +--------+
  + key_share*         -------->


                                             ServerHello
                                        + pre_shared_key  +--------+
                                            + key_share*  | Flight |
                                   {EncryptedExtensions}  +--------+
                       <--------              {Finished}
                                     [Application Data*]
                                                          +--------+
 {Finished}            -------->                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       <--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]

Client                                            Server

 ClientHello
  + early_data
  + psk_key_exchange_modes                                +--------+
  + key_share*                                            | Flight |
  + pre_shared_key                                        +--------+
 (Application Data*)     -------->

                                             ServerHello
                                        + pre_shared_key
                                            + key_share*  +--------+
                                   {EncryptedExtensions}  | Flight |
                                              {Finished}  +--------+
                       <--------     [Application Data*]


                                                          +--------+
 {Finished}            -------->                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       <--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    <------->      [Application Data]

Client                                            Server

                                                          +--------+
                       <--------       [NewSessionTicket] | Flight |
                                                          +--------+

                                                          +--------+
[ACK]                  -------->                          | Flight |
                                                          +--------+

                             +-----------+
                             | PREPARING |
                +----------> |           |
                |            |           |
                |            +-----------+
                |                  |
                |                  | Buffer next flight
                |                  |
                |                 \|/
                |            +-----------+
                |            |           |
                |            |  SENDING  |<------------------+
                |            |           |                   |
                |            +-----------+                   |
        Receive |                  |                         |
           next |                  | Send flight or partial  |
         flight |                  | flight                  |
                |                  |                         |
                |                  | Set retransmit timer    |
                |                 \|/                        |
                |            +-----------+                   |
                |            |           |                   |
                +------------|  WAITING  |-------------------+
                |     +----->|           |   Timer expires   |
                |     |      +-----------+                   |
                |     |          |  |   |                    |
                |     |          |  |   |                    |
                |     +----------+  |   +--------------------+
                |    Receive record |   Read retransmit or ACK
        Receive |  (Maybe Send ACK) |
           last |                   |
         flight |                   | Receive ACK
                |                   | for last flight
               \|/                  |
                                    |
            +-----------+           |
            |           | <---------+
            | FINISHED  |
            |           |
            +-----------+
                |  /|\
                |   |
                |   |
                +---+

          Server read retransmit
              Retransmit ACK

1. The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, adjusts and re-arms the retransmit timer (see Section 5.8.2), and returns to the WAITING state.
2. The implementation reads an ACK from the peer: upon receiving an ACK for a partial flight (as mentioned in Section 7.1), the implementation transitions to the SENDING state, where it retransmits the unacknowledged portion of the flight, adjusts and re-arms the retransmit timer, and returns to the WAITING state. Upon receiving an ACK for a complete flight, the implementation cancels all retransmissions and either remains in WAITING, or, if the ACK was for the final flight, transitions to FINISHED.
3. The implementation reads a retransmitted flight from the peer when none of the messages that it sent in response to that flight have been acknowledged: the implementation transitions to the SENDING state, where it retransmits the flight, adjusts and re-arms the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost.
4. The implementation receives some or all of the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) may also trigger the implementation to send an ACK, as described in Section 7.1.

• Profiles for specific deployment environments, such as in low-power, multi-hop mesh scenarios as used in some Internet of Things (IoT) networks, MAY specify longer timeouts. See [IOT-PROFILE] for more information about one such DTLS 1.3 IoT profile.
• Real-time protocols MAY specify shorter timeouts. It is RECOMMENDED that for DTLS-SRTP [RFC 5764], a default timeout of 400 ms be used; because customer experience degrades with one-way latencies of greater than 200 ms, real-time deployments are less likely to have long latencies.

1. NewSessionTicket
2. KeyUpdate
3. NewConnectionId
4. RequestConnectionId
5. Post-handshake client authentication

• Epoch value (0) is used with unencrypted messages. There are three unencrypted messages in DTLS, namely ClientHello, ServerHello, and HelloRetryRequest.
• Epoch value (1) is used for messages protected using keys derived from client_early_traffic_secret. Note that this epoch is skipped if the client does not offer early data.
• Epoch value (2) is used for messages protected using keys derived from [sender]_handshake_traffic_secret. Messages transmitted during the initial handshake, such as EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, and Finished, belong to this category. Note, however, that post-handshake messages are protected under the appropriate application traffic key and are not included in this category.
• Epoch value (3) is used for payloads protected using keys derived from the initial [sender]_application_traffic_secret_0. This may include handshake messages, such as post-handshake messages (e.g., a NewSessionTicket message).
• Epoch values (4 to 2^64-1) are used for payloads protected using keys from the [sender]_application_traffic_secret_N (N>0).

Client                                             Server
------                                             ------

 Record 0
 ClientHello
 (epoch=0)
                            -------->
                                                     Record 0
                            <--------       HelloRetryRequest
                                                    (epoch=0)
 Record 1
 ClientHello                -------->
 (epoch=0)
                                                     Record 1
                            <--------             ServerHello
                                                    (epoch=0)
                                        {EncryptedExtensions}
                                                    (epoch=2)
                                                {Certificate}
                                                    (epoch=2)
                                          {CertificateVerify}
                                                    (epoch=2)
                                                   {Finished}
                                                    (epoch=2)
 Record 2
 {Certificate}              -------->
 (epoch=2)
 {CertificateVerify}
 (epoch=2)
 {Finished}
 (epoch=2)
                                                     Record 2
                            <--------                   [ACK]
                                                    (epoch=3)
 Record 3
 [Application Data]         -------->
 (epoch=3)
                                                     Record 3
                            <--------      [Application Data]
                                                    (epoch=3)

                         Some time later ...
                 (Post-Handshake Message Exchange)
                                                     Record 4
                            <--------      [NewSessionTicket]
                                                    (epoch=3)
 Record 4
 [ACK]                      -------->
 (epoch=3)

                         Some time later ...
                           (Rekeying)
                                                     Record 5
                            <--------      [Application Data]
                                                    (epoch=4)
 Record 5
 [Application Data]         -------->
 (epoch=4)

    struct {
        RecordNumber record_numbers<0..2^16-1>;
    } ACK;

record_numbers:

A list of the records containing handshake messages in the currentflight which the endpoint has received and either processed or buffered,in numerically increasingorder.

• When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message.
• When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP datagram). "Immediately" is hard to define. One approach is to set a timer for 1/4 the current retransmit timer value when the first record in the flight is received and then send an ACK when that timer expires. Note: The 1/4 value here is somewhat arbitrary. Given that the round trip estimates in the DTLS handshake are generally very rough (or the default), any value will be an approximation, and there is an inherent compromise due to competition between retransmission due to over-aggressive ACKing and over-aggressive timeout-based retransmission. As a comparison point, QUIC's loss-based recovery algorithms (RFC 9002, Section 6.1.2) work out to a delay of about 1/3 of the retransmit timer.

1. Handshake flights other than the client's final flight of the main handshake.
2. The server's post-handshake CertificateRequest.

• On sign of disruption, or lack of progress; and
• To indicate complete receipt of the last flight in a handshake.

    enum {
        cid_immediate(0), cid_spare(1), (255)
    } ConnectionIdUsage;

    opaque ConnectionId<0..2^8-1>;

    struct {
        ConnectionId cids<0..2^16-1>;
        ConnectionIdUsage usage;
    } NewConnectionId;

cids:

Indicates the set of CIDs that the sender wishes the peer to use.

usage:

Indicates whether the new CIDs should be used immediately or arespare. If usage is set to "cid_immediate", then one of the new CIDsMUST be used immediately for all future records. If it is set to"cid_spare", then either an existing or new CID MAY be used.

    struct {
      uint8 num_cids;
    } RequestConnectionId;

num_cids:

The number of CIDs desired.

• The cookie MUST depend on the client's address.
• It MUST NOT be possible for anyone other than the issuing entity to generate cookies that are accepted as valid by that entity. This typically entails an integrity check based on a secret key.
• Cookie generation and verification are triggered by unauthenticated parties, and as such their resource consumption needs to be restrained in order to avoid having the cookie-exchange mechanism itself serve as a DoS vector.

• In both versions of DTLS, extension negotiation is used to agree on the use of the CID feature and the CID values. In both versions, the CID is carried in the DTLS record header (if negotiated). However, the way the CID is included in the record header differs between the two versions.
• The use of the post-handshake message allows the client and the server to update their CIDs, and those values are exchanged with confidentiality protection.
• The ability to use multiple CIDs allows for improved privacy properties in multihomed scenarios. When only a single CID is in use on multiple paths from such a host, an adversary can correlate the communication interaction across paths, which adds further privacy concerns. In order to prevent this, implementations SHOULD attempt to use fresh CIDs whenever they change local addresses or ports (though this is not always possible to detect). The RequestConnectionId message can be used by a peer to ask for new CIDs to ensure that a pool of suitable CIDs is available.
• The mechanism for encrypting sequence numbers (Section 4.2.3) prevents trivial tracking by on-path adversaries that attempt to correlate the pattern of sequence numbers received on different paths; such tracking could occur even when different CIDs are used on each path, in the absence of sequence number encryption. Switching CIDs based on certain events, or even regularly, helps against tracking by on-path adversaries. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not. Unlike the sequence number, the epoch is not encrypted because it acts as a key identifier, which may improve correlation of packets from a single connection across different network paths.
• DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions. Therefore, less information identifying the DTLS client, such as the client certificate, is available to an on-path adversary.

• New handshake pattern, which leads to a shorter message exchange.
• Only AEAD ciphers are supported. Additional data calculation has been simplified.
• Removed support for weaker and older cryptographic algorithms.
• HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.
• More flexible cipher suite negotiation.
• New session resumption mechanism.
• PSK authentication redefined.
• New key derivation hierarchy utilizing a new key derivation construct.
• Improved version negotiation.
• Optimized record layer encoding and thereby its size.
• Added CID functionality.
• Sequence numbers are encrypted.

• A version downgrade protection mechanism as described in [TLS13], Section 4.1.3 and applying to DTLS as described in Section 5.3.
• The updates described in [TLS13], Section 1.3.
• The new compliance requirements described in [TLS13], Section 9.3.

[CHACHA]

Y. Nir, and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.

[RFC0768]

J. Postel, "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.

[RFC0793]

J. Postel, "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.

[RFC1191]

J.C. Mogul, and S.E. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4443]

A. Conta, S. Deering, and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.

[RFC4821]

M. Mathis, and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.

[RFC6298]

V. Paxson, M. Allman, J. Chu, and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC9146]

E. Rescorla, H. Tschofenig, T. Fossati, and A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, DOI 10.17487/RFC9146, March 2022,
<https://www.rfc-editor.org/info/rfc9146>.

[TLS13]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[AEAD-LIMITS]

F Günther, M Thomson, and C. A. Wood, "Usage Limits on AEAD Algorithms", Internet-Draft draft-irtf-cfrg-aead-limits-04, March 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04>.

[AEBounds]

A. Luykx, and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017,
<https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.

[CCM-ANALYSIS]

J. Jonsson, "On the Security of CTR + CBC-MAC", DOI 10.1007/3-540-36492-7_7, February 2003,
<https://doi.org/10.1007/3-540-36492-7_7>.

[DEPRECATE]

K. Moriarty, and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.

[IOT-PROFILE]

Arm Limited, , and , "TLS/DTLS 1.3 Profiles for the Internet of Things", Internet-Draft draft-ietf-uta-tls13-iot-profile-04, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04>.

[RFC2522]

P. Karn, and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999,
<https://www.rfc-editor.org/info/rfc2522>.

[RFC4303]

S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.

[RFC4340]

E. Kohler, M. Handley, and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.

[RFC4346]

T. Dierks, and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006,
<https://www.rfc-editor.org/info/rfc4346>.

[RFC4347]

E. Rescorla, and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
<https://www.rfc-editor.org/info/rfc4347>.

[RFC4960]

R. Stewart, "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.

[RFC5238]

T. Phelan, "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, DOI 10.17487/RFC5238, May 2008,
<https://www.rfc-editor.org/info/rfc5238>.

[RFC5246]

T. Dierks, and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.

[RFC5763]

J. Fischl, H. Tschofenig, and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010,
<https://www.rfc-editor.org/info/rfc5763>.

[RFC5764]

D. McGrew, and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010,
<https://www.rfc-editor.org/info/rfc5764>.

[RFC6066]

D. Eastlake 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.

[RFC6347]

E. Rescorla, and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012,
<https://www.rfc-editor.org/info/rfc6347>.

[RFC7296]

C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014,
<https://www.rfc-editor.org/info/rfc7296>.

[RFC7525]

Y. Sheffer, R. Holz, and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/info/rfc7525>.

[RFC7924]

S. Santesson, and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.

[RFC7983]

M. Petit-Huguenin, and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>.

[RFC8201]

J. McCann, S. Deering, J. Mogul, and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.

[RFC8445]

A. Keranen, C. Holmberg, and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.

[RFC8879]

A. Ghedini, and V. Vasiliev, "TLS Certificate Compression", RFC 8879, DOI 10.17487/RFC8879, December 2020,
<https://www.rfc-editor.org/info/rfc8879>.

[RFC9000]

J. Iyengar, and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.

[RFC9002]

J. Iyengar, and I. Swett, "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021,
<https://www.rfc-editor.org/info/rfc9002>.

[ROBUST]

M. Fischlin, F. Günther, and C. Janson, "Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3",
<https://eprint.iacr.org/2020/718>.

[TLS-ECH]

E Rescorla, K Oku, N Sullivan, and C.A. Wood, "TLS Encrypted Client Hello", Internet-Draft draft-ietf-tls-esni-14, February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14>.

t:

The size of the authentication tag in bits. For this cipher, t is 128.

n:

The size of the block function in bits. For this cipher, n is 128.

l:

The number of blocks in each packet (see below).

q:

The number of genuine packets created and protected by endpoints. This valueis the bound on the number of packets that can be protected before updatingkeys.

v:

The number of forged packets that endpoints will accept. This value is thebound on the number of forged packets that an endpoint can reject beforeupdating keys.

• Do you correctly handle messages received from multiple epochs during a key transition? This includes locating the correct key as well as performing replay detection, if enabled.
• Do you retransmit handshake messages that are not (implicitly or explicitly) acknowledged (Section 5.8)?
• Do you correctly handle handshake message fragments received, including when they are out of order?
• Do you correctly handle handshake messages received out of order? This may include either buffering or discarding them.
• Do you limit how much data you send to a peer before its address is validated?
• Do you verify that the explicit record length is contained within the datagram in which it is contained?

Hanno Becker

David Benjamin

Thomas Fossati

Tobias Gondrom

Felix Günther

Benjamin Kaduk

Ilari Liusvaara

Martin Thomson

Christopher A. Wood

Yin Xinxing

Eric Rescorla

Hannes Tschofenig

Nagendra Modadugu