3.1.Packet Loss

DTLS uses a simple retransmission timer to handle packet loss.Figure 1 demonstrates the basic concept, using the firstphase of the DTLS handshake:¶

         Client                                   Server         ------                                   ------         ClientHello           ------>                                 X<-- HelloRetryRequest                                                  (lost)         [Timer Expires]         ClientHello           ------>         (retransmit)

Once the client has transmitted the ClientHello message, it expectsto see a HelloRetryRequest or a ServerHello from the server. However, if thetimer expires, the client knows that either theClientHello or the response from the server has been lost, whichcauses the clientto retransmit the ClientHello. When the server receives the retransmission,it knows to retransmit its HelloRetryRequest or ServerHello.¶

The server also maintains a retransmission timer for messages itsends (other than HelloRetryRequest) and retransmits when that timer expires. Notapplying retransmissions to the HelloRetryRequest avoids the need tocreate state on the server. The HelloRetryRequest is designed to besmall enough that it will not itself be fragmented, thus avoidingconcerns about interleaving multiple HelloRetryRequests.¶

For more detail on timeouts and retransmission,seeSection 5.8.¶

3.2.Reordering

In DTLS, each handshake message is assigned a specific sequencenumber. When a peer receives a handshakemessage, it can quickly determine whether that message is the nextmessage it expects. If it is, then it processes it. If not, itqueues it for future handling once all previous messages have beenreceived.¶

3.3.Fragmentation

TLS and DTLS handshake messages can be quite large (in theory up to2^24-1 bytes, in practice many kilobytes). By contrast, UDPdatagrams are often limited to less than 1500 bytes if IP fragmentation is notdesired. In order to compensate for this limitation, each DTLShandshake message may be fragmented over several DTLS records, eachof which is intended to fit in a single UDP datagram(seeSection 4.4 for guidance). Each DTLShandshake message contains both a fragment offset and a fragmentlength. Thus, a recipient in possession of all bytes of a handshakemessage can reassemble the original unfragmented message.¶

3.4.Replay Detection

DTLS optionally supports record replay detection. The technique usedis the same as in IPsec AH/ESP, by maintaining a bitmap window ofreceived records. Records that are too old to fit in the window andrecords that have previously been received are silently discarded.The replay detection feature is optional, since packet duplication isnot always malicious but can also occur due to routing errors.Applications may conceivably detect duplicate packets and accordinglymodify their data transmission strategy.¶

4.1.Demultiplexing DTLS Records

DTLS 1.3's header format is more complicated to demux thanDTLS 1.2, which always carried the content type as the firstbyte. As described inFigure 5, the first byte determines how an incomingDTLS record is demultiplexed. The first 3 bits of the first bytedistinguish a DTLS 1.3 encrypted record from record types used inprevious DTLS versions and plaintext DTLS 1.3 record types. Hence, therange 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excludedfrom future allocations by IANA to avoid problems while demultiplexing;seeSection 14.Implementations can demultiplex DTLS 1.3 recordsby examining the first byte as follows:¶

• If the first byte is alert(21), handshake(22), or ack(proposed, 26),the recordMUST be interpreted as a DTLSPlaintext record.¶
• If the first byte is any other value, then receiversMUST check to see if the leading bits of the first byte are001. If so, the implementationMUST process the record asDTLSCiphertext; the true content type will be inside theprotected portion.¶
• Otherwise, the recordMUST be rejected as if it had faileddeprotection, as described inSection 4.5.2.¶

Figure 5 shows this demultiplexing procedure graphically,taking DTLS 1.3 and earlier versions of DTLS into account.¶

             +----------------+             | 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                            +----------------+

4.2.Sequence Number and Epoch

DTLS uses an explicit or partly explicit sequence number, rather than an implicit one,carried in the sequence_number field of the record. Sequence numbersare maintained separately for each epoch, with each sequence_numberinitially being 0 for each epoch.¶

The epoch number is initially zero and is incremented each timekeying material changes and a sender aims to rekey. More detailsare provided inSection 6.1.¶

  Mask = AES-ECB(sn_key, Ciphertext[0..15])

  Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])

  [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)

4.3.Transport Layer Mapping

DTLS messagesMAY be fragmented into multiple DTLS records.Each DTLS recordMUST fit within a single datagram. In order toavoid IP fragmentation, clients of the DTLS record layerSHOULDattempt to size records so that they fit within any Path MTU (PMTU) estimatesobtained from the record layer. For more information about PMTU issues,seeSection 4.4.¶

Multiple DTLS recordsMAY be placed in a single datagram. Records are encodedconsecutively. The length field from DTLS records containing that field can beused to determine the boundaries between records. The final record in adatagram can omit the length field. The first byte of the datagram payloadMUSTbe the beginning of a record. RecordsMUST NOT span datagrams.¶

DTLS records without CIDs do not contain any associationidentifiers, and applications must arrange to multiplex between associations.With UDP, the host/port number is used to look up the appropriate securityassociation for incoming records without CIDs.¶

Some transports, such as DCCP[RFC4340], provide their own sequencenumbers. When carried over those transports, both the DTLS and thetransport sequence numbers will be present. Although this introducesa small amount of inefficiency, the transport layer and DTLS sequencenumbers serve different purposes; therefore, for conceptual simplicity,it is superior to use both sequence numbers.¶

Some transports provide congestion control for trafficcarried over them. If the congestion window is sufficiently narrow,DTLS handshake retransmissions may be held rather than transmittedimmediately, potentially leading to timeouts and spuriousretransmission. When DTLS is used over such transports, care shouldbe taken not to overrun the likely congestion window.[RFC5238]defines a mapping of DTLS to DCCP that takes these issues into account.¶

4.4.PMTU Issues

In general, DTLS's philosophy is to leave PMTU discovery to the application.However, DTLS cannot completely ignore the PMTU for three reasons:¶

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

In order to deal with the first two issues, the DTLS record layerSHOULD behave as described below.¶

If PMTU estimates are available from the underlying transportprotocol, they should be made available to upper layerprotocols. In particular:¶

• For DTLS over UDP, the upper layer protocolSHOULD be allowed toobtain the PMTU estimate maintained in the IP layer.¶
• For DTLS over DCCP, the upper layer protocolSHOULD be allowed toobtain the current estimate of the PMTU.¶
• For DTLS over TCP or SCTP, which automatically fragment andreassemble datagrams, there is no PMTU limitation. However, theupper layer protocolMUST NOT write any record that exceeds themaximum record size of 2^14 bytes.¶

The DTLS record layerSHOULD also allow the upper layer protocol todiscover the amount of record expansion expected by the DTLSprocessing; alternately, itMAY report PMTU estimates minus theestimated expansion from the transport layer and DTLS recordframing.¶

Note that DTLS does not defend against spoofed ICMP messages;implementationsSHOULD ignore any such messages that indicatePMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes,respectively.¶

If there is a transport protocol indication that the PMTU was exceeded(either via ICMP or via arefusal to send the datagram as inSection 14 of [RFC4340]), then theDTLS record layerMUST inform the upper layer protocol of the error.¶

The DTLS record layerSHOULD NOT interfere with upper layer protocolsperforming PMTU discovery, whether via[RFC1191] and[RFC4821] forIPv4 or via[RFC8201] for IPv6. In particular:¶

• Where allowed by the underlying transport protocol, the upperlayer protocolSHOULD 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 torequest PMTU probing (e.g., DCCP), the DTLS record layerSHOULDhonor this request.¶

The final issue is the DTLS handshake protocol. From the perspectiveof the DTLS record layer, this is merely another upper layerprotocol. However, DTLS handshakes occur infrequently and involveonly a few round trips; therefore, the handshake protocol PMTUhandling places a premium on rapid completion over accurate PMTUdiscovery. In order to allow connections under these circumstances,DTLS implementationsSHOULD follow the following rules:¶

• If the DTLS record layer informs the DTLS handshake layer that amessage is too big, the handshake layerSHOULD immediately attempt to fragmentthe message, using any existing information about the PMTU.¶
• If repeated retransmissions do not result in a response, and thePMTU is unknown, subsequent retransmissionsSHOULD back off to asmaller record size, fragmenting the handshake message asappropriate. This specification does not specify an exact number ofretransmits to attempt before backing off, but 2-3 seemsappropriate.¶

4.5.Record Payload Protection

Like TLS, DTLS transmits data as a series of protected records. Therest of this section describes the details of that format.¶

5.1.Denial-of-Service Countermeasures

Datagram security protocols are extremely susceptible to a variety ofDoS attacks. Two attacks are of particular concern:¶

1. An attacker can consume excessive resources on the server bytransmitting a series of handshake initiation requests, causingthe server to allocate state and potentially to performexpensive cryptographic operations.¶
2. An attacker can use the server as an amplifier by sendingconnection initiation messages with a forged source address that belongs to avictim. The server then sends its response to the victimmachine, thus flooding it. Depending on the selectedparameters, this response message can be quite large, asis the case for a Certificate message.¶

In order to counter both of these attacks, DTLS borrows the statelesscookie technique used by Photuris[RFC2522] and IKE[RFC7296]. Whenthe client sends its ClientHello message to the server, the serverMAY respond with a HelloRetryRequest message. The HelloRetryRequest message,as well as the "cookie" extension, is defined in TLS 1.3.The HelloRetryRequest message contains a stateless cookie (see[TLS13],Section 4.2.2).The clientMUST send a new ClientHellowith the cookie added as an extension. The server then verifies the cookieand proceeds with the handshake only if it is valid. This mechanism forcesthe attacker/client to be able to receive the cookie, which makes DoS attackswith spoofed IP addresses difficult. This mechanism does not provide any defenseagainst DoS attacks mounted from valid IP addresses.¶

The DTLS 1.3 specification changes how cookies are exchangedcompared to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest messageand conveys the cookie to the client via an extension. The clientreceiving the cookie uses the same extension to placethe cookie subsequently into a ClientHello message.DTLS 1.2, on the other hand, used a separate message, namely the HelloVerifyRequest,to pass a cookie to the client and did not utilize the extension mechanism.For backwards compatibility reasons, the cookie field in the ClientHellois present in DTLS 1.3 but is ignored by a DTLS 1.3-compliant serverimplementation.¶

The exchange is shown inFigure 6. Note thatthe figure focuses on the cookie exchange; all other extensionsare omitted.¶

      Client                                   Server      ------                                   ------      ClientHello           ------>                            <----- HelloRetryRequest                                    + cookie      ClientHello           ------>       + cookie      [Rest of handshake]

The "cookie" extension is defined inSection 4.2.2 of [TLS13]. When sending theinitial ClientHello, the client does not have a cookie yet. In this case,the "cookie" extension is omitted and the legacy_cookie field in the ClientHellomessageMUST be set to a zero-length vector (i.e., a zero-valued single byte length field).¶

When responding to a HelloRetryRequest, the clientMUST create a newClientHello message following the description inSection 4.1.2 of [TLS13].¶

If the HelloRetryRequest message is used, the initial ClientHello andthe HelloRetryRequest are included in the calculation of thetranscript hash. The computation of themessage hash for the HelloRetryRequest is done according to the descriptioninSection 4.4.1 of [TLS13].¶

The handshake transcript is not reset with the second ClientHello,and a stateless server-cookie implementation requires the content or hashof the initial ClientHello (and HelloRetryRequest)to be stored in the cookie. The initial ClientHello is included in thehandshake transcript as a synthetic "message_hash" message, so only the hashvalue is needed for the handshake to complete, though the completeHelloRetryRequest contents are needed.¶

When the second ClientHello is received, the server can verify thatthe cookie is valid and that the client can receive packets at thegiven IP address. If the client's apparent IP address is embeddedin the cookie, this prevents an attacker from generating an acceptableClientHello apparently from another user.¶

One potential attack on this scheme is for the attacker to collect anumber of cookies from different addresses where it controls endpointsand then reuse them to attack the server.The server can defend against this attack bychanging the secret value frequently, thus invalidating thosecookies. If the server wishes to allow legitimate clients tohandshake through the transition (e.g., a client received a cookie withSecret 1 and then sent the second ClientHello after the server haschanged to Secret 2), the server can have a limited window duringwhich it accepts both secrets.[RFC7296] suggests adding a keyidentifier to cookies to detect this case. An alternative approach issimply to try verifying with both secrets. It isRECOMMENDED thatservers implement a key rotation scheme that allows the serverto manage keys with overlapping lifetimes.¶

Alternatively, the server can store timestamps in the cookie andreject cookies that were generated outside a certaininterval of time.¶

DTLS serversSHOULD perform a cookie exchange whenever a newhandshake is being performed. If the server is being operated in anenvironment where amplification is not a problem, e.g., whereICE[RFC8445] has been used to establish bidirectional connectivity,the serverMAY beconfigured not to perform a cookie exchange. The defaultSHOULD bethat the exchange is performed, however. In addition, the serverMAYchoose not to do a cookie exchange when a session is resumed or, moregenerically, when the DTLS handshake uses a PSK-based key exchangeand the IP address matches one associated with the PSK.Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.A serverSHOULD limit the amount of data it sends toward a client addressto three times the amount of data sent by the client beforeit verifies that the client is able to receive data at that address.A client address is valid after a cookie exchange or handshake completion.ClientsMUST be prepared to do a cookie exchange with everyhandshake. Note that cookies are only valid for the existinghandshake and cannot be stored for future handshakes.¶

If a server receives a ClientHello with an invalid cookie, itMUST terminate the handshake with an "illegal_parameter" alert.This allows the client to restart the connection fromscratch without a cookie.¶

As described inSection 4.1.4 of [TLS13], clientsMUSTabort the handshake with an "unexpected_message" alert in responseto any second HelloRetryRequest which was sent in the same connection(i.e., where the ClientHello was itself in response to a HelloRetryRequest).¶

DTLS clients which do not want to receive a Connection IDSHOULDstill offer the "connection_id" extension[RFC9146] unlessthere is an application profile to the contrary. This permitsa server which wants to receive a CID to negotiate one.¶

5.2.DTLS Handshake Message Format

DTLS uses the same Handshake messages as TLS 1.3. However,prior to transmission they are converted to DTLSHandshakemessages, which contain extra data needed to supportmessage loss, reordering, and message fragmentation.¶

    enum {        client_hello(1),        server_hello(2),        new_session_ticket(4),        end_of_early_data(5),        encrypted_extensions(8),        request_connection_id(9),           /* New */        new_connection_id(10),              /* New */        certificate(11),        certificate_request(13),        certificate_verify(15),        finished(20),        key_update(24),        message_hash(254),        (255)    } HandshakeType;

    struct {        HandshakeType msg_type;    /* handshake type */        uint24 length;             /* bytes in message */        uint16 message_seq;        /* DTLS-required field */        uint24 fragment_offset;    /* DTLS-required field */        uint24 fragment_length;    /* DTLS-required field */        select (msg_type) {            case client_hello:          ClientHello;            case server_hello:          ServerHello;            case end_of_early_data:     EndOfEarlyData;            case encrypted_extensions:  EncryptedExtensions;            case certificate_request:   CertificateRequest;            case certificate:           Certificate;            case certificate_verify:    CertificateVerify;            case finished:              Finished;            case new_session_ticket:    NewSessionTicket;            case key_update:            KeyUpdate;            case request_connection_id: RequestConnectionId;            case new_connection_id:     NewConnectionId;        } body;    } DTLSHandshake;

In DTLS 1.3, the message transcript is computed over the originalTLS 1.3-style Handshake messages without the message_seq,fragment_offset, and fragment_length values. Note that this isa change from DTLS 1.2 where those values were includedin the transcript.¶

The first message each side transmits in each association always hasmessage_seq = 0. Whenever a new message is generated, themessage_seq value is incremented by one. When a message isretransmitted, the old message_seq value is reused, i.e., notincremented. From the perspective of the DTLS record layer, the retransmission isa new record. This record will have a newDTLSPlaintext.sequence_number value.¶

Note: In DTLS 1.2, the message_seq was reset to zero in case of arehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2shares similarities with a post-handshake message exchange in DTLS 1.3. However,in DTLS 1.3 the message_seq is not reset, to allow distinguishing aretransmission from a previously sent post-handshake message from a newlysent post-handshake message.¶

DTLS implementations maintain (at least notionally) anext_receive_seq counter. This counter is initially set to zero.When a handshake message is received, if its message_seq value matchesnext_receive_seq, next_receive_seq is incremented and the message isprocessed. If the sequence number is less than next_receive_seq, themessageMUST be discarded. If the sequence number is greater thannext_receive_seq, the implementationSHOULD queue the message butMAYdiscard it. (This is a simple space/bandwidth trade-off).¶

In addition to the handshake messages that are deprecated by the TLS 1.3specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest messageoriginally defined in DTLS 1.0. DTLS 1.3-compliant implementationsMUST NOTuse the HelloVerifyRequest to execute a return-routability check. Adual-stack DTLS 1.2 / DTLS 1.3 clientMUST, however, be prepared tointeract with a DTLS 1.2 server.¶

5.3.ClientHello Message

The format of the ClientHello used by a DTLS 1.3 client differs from theTLS 1.3 ClientHello format, as shown below.¶

    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 (seeSection 4.2.1 of [TLS13]) and thelegacy_version fieldMUST 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 describedinSection 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 serverSHOULD set thisfield to that value. Otherwise, itMUST be set as a zero-length vector(i.e., a zero-valued single byte length field).¶

legacy_cookie:

A DTLS 1.3-only clientMUST set the legacy_cookie field to zero length.If a DTLS 1.3 ClientHello is received with any other value in this field,the serverMUST 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.¶

5.4.ServerHello Message

The DTLS 1.3 ServerHello message is the same as the TLS 1.3ServerHello message, except that the legacy_version fieldis set to 0xfefd, indicating DTLS 1.2.¶

5.5.Handshake Message Fragmentation and Reassembly

As described inSection 4.3, one or more handshakemessages may be carried in a single datagram. However, handshake messages arepotentially bigger than the size allowed by the underlying datagram transport.DTLS provides a mechanism for fragmenting a handshake message over anumber of records, each of which can be transmitted in separate datagrams, thusavoiding IP fragmentation.¶

When transmitting the handshake message, the sender divides themessage into a series of N contiguous data ranges. The rangesMUST NOToverlap. The sender then creates N DTLSHandshake messages, all with thesame message_seq value as the original DTLSHandshake message. Each newmessage is labeled with the fragment_offset (the number of bytescontained in previous fragments) and the fragment_length (the lengthof this fragment). The length field in all messages is the same asthe length field of the original message. An unfragmented message isa degenerate case with fragment_offset=0 and fragment_length=length.Each handshake message fragment that is placed into a recordMUST be delivered in a single UDP datagram.¶

When a DTLS implementation receives a handshake message fragment correspondingto the next expected handshake message sequence number, itMUST process it, either by buffering it until it has the entirehandshake message or by processing any in-order portions of the message.The transcript consists of complete TLS Handshake messages (reassembledas necessary). Note that this requires removing the message_seq,fragment_offset, and fragment_length fields to create the Handshakestructure.¶

DTLSimplementationsMUST be able to handle overlapping fragment ranges.This allows senders to retransmit handshake messages with smallerfragment sizes if the PMTU estimate changes. SendersMUST NOT changehandshake message bytes upon retransmission. ReceiversMAY checkthat retransmitted bytes are identical andSHOULD abort the handshakewith an "illegal_parameter" alert if the value of a byte changes.¶

Note that as with TLS, multiple handshake messages may be placed inthe same DTLS record, provided that there is room and that they arepart of the same flight. Thus, there are two acceptable ways to packtwo DTLS handshake messages into the same datagram: in the same record or inseparate records.¶

5.6.EndOfEarlyData Message

The DTLS 1.3 handshake has one important difference from theTLS 1.3 handshake: the EndOfEarlyData message is omitted bothfrom the wire and the handshake transcript. Because DTLSrecords have epochs, EndOfEarlyData is not necessary to determinewhen the early data is complete, and because DTLS is lossy,attackers can trivially mount the deletion attacks that EndOfEarlyDataprevents in TLS. ServersSHOULD NOT accept records from epoch 1 indefinitely once they are able to process records from epoch 3. Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time. Servers could discard epoch 1 keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.(SeeSection 6.1 for the definitions of each epoch.)¶

5.7.DTLS Handshake Flights

DTLS handshake messages are grouped into a series of message flights. A flight starts with thehandshake message transmission of one peer and ends with the expected response from theother peer.Table 1 contains a complete list of message combinations that constitute flights.¶

Remarks:¶

• 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.¶

Below are several example message exchanges illustrating the flight concept.The notational conventions from[TLS13] are used.¶

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 |                                                          +--------+

KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar patternto NewSessionTicket: a single message sent by one sidefollowed by an ACK by the other.¶

5.8.Timeout and Retransmission

                             +-----------+                             | 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

5.9.Cryptographic Label Prefix

Section 7.1 of [TLS13] specifies that HKDF-Expand-Label usesa label prefix of "tls13 ". For DTLS 1.3, that labelSHALL be"dtls13". This ensures key separation between DTLS 1.3 andTLS 1.3. Note that there is no trailing space; this is necessaryin order to keep the overall label size inside of one hashiteration because "DTLS" is one letter longer than "TLS".¶

5.10.Alert Messages

Note that alert messages are not retransmitted at all, even when theyoccur in the context of a handshake. However, a DTLS implementationwhich would ordinarily issue an alertSHOULD generate a new alertmessage if the offending record is received again (e.g., as aretransmitted handshake message). ImplementationsSHOULD detect whena peer is persistently sending bad messages and terminate the localconnection state after such misbehavior is detected. Note that alertsare not reliably transmitted; implementationsSHOULD NOT depend onreceiving alerts in order to signal errors or connection closure.¶

Any data received with an epoch/sequence number pair afterthat of a valid received closure alertMUST be ignored. Note:this is a change from TLS 1.3 which depends on the order ofreceipt rather than the epoch and sequence number.¶

5.11.Establishing New Associations with Existing Parameters

If a DTLS client-server pair is configured in such a way thatrepeated connections happen on the same host/port quartet, then it ispossible that a client will silently abandon one connection and theninitiate another with the same parameters (e.g., after a reboot).This will appear to the server as a new handshake with epoch=0. Incases where a server believes it has an existing association on agiven host/port quartet and it receives an epoch=0 ClientHello, itSHOULD proceed with a new handshake butMUST NOT destroy the existingassociation until the client has demonstrated reachability either bycompleting a cookie exchange or by completing a complete handshakeincluding delivering a verifiable Finished message. After a correctFinished message is received, the serverMUST abandon the previousassociation to avoid confusion between two valid associations withoverlapping epochs. The reachability requirement preventsoff-path/blind attackers from destroying associations merely bysending forged ClientHellos.¶

Note: It is not always possible to distinguish which associationa given record is from. For instance, if the client performsa handshake, abandons the connection, and then immediately startsa new handshake, it may not be possible to tell which connectiona given protected record is for. In these cases, trial decryptionmay be necessary, though implementations could use CIDs to avoidthe 5-tuple-based ambiguity.¶

6.1.Epoch Values and Rekeying

A recipient of a DTLS message needs to select the correct keying materialin order to process an incoming message. With the possibility of message loss and reordering, an identifier is needed to determine which cipher statehas been used to protect the record payload. The epoch value fulfills thisrole in DTLS. In addition to the TLS 1.3-defined key derivation steps (seeSection 7 of [TLS13]), a sender may want to rekey at any time duringthe lifetime of the connection. It therefore needs to indicate that it isupdating its sending cryptographic keys.¶

This version of DTLS assigns dedicated epoch values to messages in theprotocol exchange to allow identification of the correct cipher state:¶

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

Using these reserved epoch values, a receiver knows what cipher statehas been used to encrypt and integrity protect amessage. Implementations that receive a record with an epoch valuefor which no corresponding cipher state can be determinedSHOULDhandle it as a record which fails deprotection.¶

Note that epoch values do not wrap. If a DTLS implementation wouldneed to wrap the epoch value, itMUST terminate the connection.¶

The traffic key calculation is described inSection 7.3 of [TLS13].¶

Figure 13 illustrates the epoch values in an example DTLS handshake.¶

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)

7.1.Sending ACKs

When an implementation detects a disruption in the receipt of thecurrent incoming flight, itSHOULD generate an ACK that covers themessages from that flight which it has received and processed so far.Implementations have some discretion about which events to treatas signs of disruption, but it isRECOMMENDED that they generateACKs under two circumstances:¶

• When they receive a message or fragment which is out of order,either because it is not the next expected message or becauseit is not the next piece of the current message.¶
• When they have received part of a flight and do not immediatelyreceive the rest of the flight (which may be in the same UDPdatagram). "Immediately" is hard to define. One approach is toset a timer for 1/4 the current retransmit timer value whenthe first record in the flight is received and then send anACK when that timer expires. Note: The 1/4 value here is somewhatarbitrary. Given that the round trip estimates in the DTLShandshake are generally very rough (or the default), anyvalue will be an approximation, and there is an inherentcompromise due to competition between retransmission due to over-aggressive ACKingand over-aggressive timeout-based retransmission.As a comparison point,QUIC's loss-based recovery algorithms([RFC9002],Section 6.1.2)work out to a delay of about 1/3 of the retransmit timer.¶

In general, flightsMUST be ACKed unless they are implicitlyacknowledged. In the present specification, the following flights are implicitly acknowledgedby the receipt of the next flight, which generally immediately follows the flight:¶

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

ACKsSHOULD NOT be sent for these flights unless the responding flight cannot be generated immediately. All other flightsMUST be ACKed.In this case,implementationsMAY send explicit ACKs for the complete receivedflight even though it will eventually also be implicitly acknowledgedthrough the responding flight. A notable example for this isthe case of client authentication in constrainedenvironments, where generating the CertificateVerify message cantake considerable time on the client.ImplementationsMAY acknowledge the records corresponding to each transmission ofeach flight or simply acknowledge the most recent one. In general,implementationsSHOULD ACK as many received packets as can fitinto the ACK record, as this provides the most complete informationand thus reduces the chance of spurious retransmission; if spaceis limited, implementationsSHOULD favor including records whichhave not yet been acknowledged.¶

Note: While some post-handshake messages follow a request/responsepattern, this does not necessarily imply receipt.For example, a KeyUpdate sent in response to a KeyUpdate withrequest_update set to "update_requested" does not implicitlyacknowledge the earlier KeyUpdate message because the two KeyUpdatemessages might have crossed in flight.¶

ACKsMUST NOT be sent for records of any content typeother than handshake or for records which cannot be deprotected.¶

Note that in some cases it may be necessary to send an ACK whichdoes not contain any record numbers. For instance, a clientmight receive an EncryptedExtensions message prior to receivinga ServerHello. Because it cannot decrypt the EncryptedExtensions,it cannot safely acknowledge it (as it might be damaged). If the clientdoes not send an ACK, the server will eventually retransmitits first flight, but this might take far longer than theactual round trip time between client and server. Havingthe client send an empty ACK shortcuts this process.¶

7.2.Receiving ACKs

When an implementation receives an ACK, itSHOULD record that themessages or message fragments sent in the records beingACKed were received and omit them from any futureretransmissions. Upon receipt of an ACK that leaves it withonly some messages from a flight having been acknowledged,an implementationSHOULD retransmit the unacknowledgedmessages or fragments. Note that this requires implementations totrack which messages appear in which records. Once all the messages in a flight have beenacknowledged, the implementationMUST cancel all retransmissionsof that flight.ImplementationsMUST treat a recordas having been acknowledged if it appears in any ACK; thisprevents spurious retransmission in cases where a flight isvery large and the receiver is forced to elide acknowledgementsfor records which have already been ACKed.As noted above, the receipt of any record respondingto a given flightMUST be taken as an implicit acknowledgement for the entireflight to which it is responding.¶

7.3.Design Rationale

ACK messages are used in two circumstances, namely:¶

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

In the first case, the use of the ACK message is optional, because the peer will retransmit in any case and therefore the ACK just allows for selective or early retransmission, as opposed to the timeout-based whole flight retransmission in previous versions of DTLS. When DTLS 1.3 is used in deploymentswith lossy networks, such as low-power, long-range radio networks as well aslow-power mesh networks, the use of ACKs is recommended.¶

The use of the ACK for the second case is mandatory for the proper functioning of theprotocol. For instance, the ACK message sent by the client inFigure 13acknowledges receipt and processing of Record 4 (containing the NewSessionTicketmessage), and if it is not sent, the server will continue retransmissionof the NewSessionTicket indefinitely until its maximum retransmission count is reached.¶

9.1.Connection ID Example

Below is an example exchange for DTLS 1.3 using a singleCID in each direction.¶

Note: The "connection_id" extension, which is used in ClientHello and ServerHello messages, is defined in[RFC9146].¶

Client                                             Server------                                             ------ClientHello(connection_id=5)                            -------->                            <--------       HelloRetryRequest                                                     (cookie)ClientHello                 -------->(connection_id=5)  + cookie                            <--------             ServerHello                                          (connection_id=100)                                          EncryptedExtensions                                                      (cid=5)                                                  Certificate                                                      (cid=5)                                            CertificateVerify                                                      (cid=5)                                                     Finished                                                      (cid=5)Certificate                -------->(cid=100)CertificateVerify(cid=100)Finished(cid=100)                           <--------                      ACK                                                      (cid=5)Application Data           ========>(cid=100)                           <========         Application Data                                                      (cid=5)

If no CID is negotiated, then the receiverMUST reject anyrecords it receives that contain a CID.¶

A.1.Record Layer

    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;    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)  |    +-+-+-+-+-+-+-+-+    struct {        uint64 epoch;        uint64 sequence_number;    } RecordNumber;

A.2.Handshake Protocol

    enum {        hello_request_RESERVED(0),        client_hello(1),        server_hello(2),        hello_verify_request_RESERVED(3),        new_session_ticket(4),        end_of_early_data(5),        hello_retry_request_RESERVED(6),        encrypted_extensions(8),        request_connection_id(9),           /* New */        new_connection_id(10),              /* New */        certificate(11),        server_key_exchange_RESERVED(12),        certificate_request(13),        server_hello_done_RESERVED(14),        certificate_verify(15),        client_key_exchange_RESERVED(16),        finished(20),        certificate_url_RESERVED(21),        certificate_status_RESERVED(22),        supplemental_data_RESERVED(23),        key_update(24),        message_hash(254),        (255)    } HandshakeType;    struct {        HandshakeType msg_type;    /* handshake type */        uint24 length;             /* bytes in message */        uint16 message_seq;        /* DTLS-required field */        uint24 fragment_offset;    /* DTLS-required field */        uint24 fragment_length;    /* DTLS-required field */        select (msg_type) {            case client_hello:          ClientHello;            case server_hello:          ServerHello;            case end_of_early_data:     EndOfEarlyData;            case encrypted_extensions:  EncryptedExtensions;            case certificate_request:   CertificateRequest;            case certificate:           Certificate;            case certificate_verify:    CertificateVerify;            case finished:              Finished;            case new_session_ticket:    NewSessionTicket;            case key_update:            KeyUpdate;            case request_connection_id: RequestConnectionId;            case new_connection_id:     NewConnectionId;        } body;    } 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;

A.3.ACKs

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

A.4.Connection ID Management

    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;    struct {      uint8 num_cids;    } RequestConnectionId;

B.1.Confidentiality Limits

For confidentiality, Theorem 2 in[CCM-ANALYSIS] establishes that an attackergains a distinguishing advantage over an ideal pseudorandom permutation (PRP) ofno more than:¶

(2l * q)^2 / 2^n

For a target advantage in a single-key setting of 2^-60, which matches that used by TLS 1.3, as summarized in[AEAD-LIMITS], this results in the relation:¶

q <= 2^23

That is, endpoints cannot protect more than 2^23 packets with the same set ofkeys without causing an attacker to gain a larger advantage than the target of2^-60.¶

B.2.Integrity Limits

For integrity, Theorem 1 in[CCM-ANALYSIS] establishes that an attackergains an advantage over an ideal PRP of no more than:¶

v / 2^t + (2l * (v + q))^2 / 2^n

The goal is to limit this advantage to 2^-57, to match the target inTLS 1.3, as summarized in[AEAD-LIMITS]. Ast andn are both 128, the first term is negligible relativeto the second, so that term can be removed without a significant effect on theresult. This produces the relation:¶

v + q <= 2^24.5

Using the previously established value of 2^23 forq and rounding, this leadsto an upper limit onv of 2^23.5. That is, endpoints cannot attempt toauthenticate more than 2^23.5 packets with the same set of keys without causingan attacker to gain a larger advantage than the target of 2^-57.¶

B.3.Limits for AEAD_AES_128_CCM_8

The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 function,which uses a short authentication tag (that is, t=64).¶

The confidentiality limits of AEAD_AES_128_CCM_8 are the same as those forAEAD_AES_128_CCM, as this does not depend on the tag length; seeAppendix B.1.¶

The shorter tag length of 64 bits means that the simplification used inAppendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is topreserve the same margins as other cipher suites, then the limit on forgeriesis largely dictated by the first term of the advantage formula:¶

v <= 2^7

As this represents attempts that fail authentication, applying this limit mightbe feasible in some environments. However, applying this limit in animplementation intended for general use exposes connections to an inexpensivedenial-of-service attack.¶

This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitablefor general use. Specifically, TLS_AES_128_CCM_8_SHA256 cannot be used withoutadditional measures to prevent forgery of records, or to mitigate the effect offorgeries. This might require understanding the constraints that exist in aparticular deployment or application. For instance, it might be possible to seta different target for the advantage an attacker gains based on anunderstanding of the constraints imposed on a specific usage of DTLS.¶