diff options
Diffstat (limited to 'doc/rfc/rfc9147.txt')
| -rw-r--r-- | doc/rfc/rfc9147.txt | 3103 |
1 files changed, 3103 insertions, 0 deletions
diff --git a/doc/rfc/rfc9147.txt b/doc/rfc/rfc9147.txt new file mode 100644 index 0000000..9934bc7 --- /dev/null +++ b/doc/rfc/rfc9147.txt @@ -0,0 +1,3103 @@ + + + + +Internet Engineering Task Force (IETF) E. Rescorla +Request for Comments: 9147 Mozilla +Obsoletes: 6347 H. Tschofenig +Category: Standards Track Arm Limited +ISSN: 2070-1721 N. Modadugu + Google, Inc. + April 2022 + + + The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 + +Abstract + + This document specifies version 1.3 of the Datagram Transport Layer + Security (DTLS) protocol. DTLS 1.3 allows client/server applications + to communicate over the Internet in a way that is designed to prevent + eavesdropping, tampering, and message forgery. + + The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) + 1.3 protocol and provides equivalent security guarantees with the + exception of order protection / non-replayability. Datagram + semantics of the underlying transport are preserved by the DTLS + protocol. + + This document obsoletes RFC 6347. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9147. + +Copyright Notice + + Copyright (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction + 2. Conventions and Terminology + 3. DTLS Design Rationale and Overview + 3.1. Packet Loss + 3.2. Reordering + 3.3. Fragmentation + 3.4. Replay Detection + 4. The DTLS Record Layer + 4.1. Demultiplexing DTLS Records + 4.2. Sequence Number and Epoch + 4.2.1. Processing Guidelines + 4.2.2. Reconstructing the Sequence Number and Epoch + 4.2.3. Record Number Encryption + 4.3. Transport Layer Mapping + 4.4. PMTU Issues + 4.5. Record Payload Protection + 4.5.1. Anti-Replay + 4.5.2. Handling Invalid Records + 4.5.3. AEAD Limits + 5. The DTLS Handshake Protocol + 5.1. Denial-of-Service Countermeasures + 5.2. DTLS Handshake Message Format + 5.3. ClientHello Message + 5.4. ServerHello Message + 5.5. Handshake Message Fragmentation and Reassembly + 5.6. EndOfEarlyData Message + 5.7. DTLS Handshake Flights + 5.8. Timeout and Retransmission + 5.8.1. State Machine + 5.8.2. Timer Values + 5.8.3. Large Flight Sizes + 5.8.4. State Machine Duplication for Post-Handshake Messages + 5.9. Cryptographic Label Prefix + 5.10. Alert Messages + 5.11. Establishing New Associations with Existing Parameters + 6. Example of Handshake with Timeout and Retransmission + 6.1. Epoch Values and Rekeying + 7. ACK Message + 7.1. Sending ACKs + 7.2. Receiving ACKs + 7.3. Design Rationale + 8. Key Updates + 9. Connection ID Updates + 9.1. Connection ID Example + 10. Application Data Protocol + 11. Security Considerations + 12. Changes since DTLS 1.2 + 13. Updates Affecting DTLS 1.2 + 14. IANA Considerations + 15. References + 15.1. Normative References + 15.2. Informative References + Appendix A. Protocol Data Structures and Constant Values + A.1. Record Layer + A.2. Handshake Protocol + A.3. ACKs + A.4. Connection ID Management + Appendix B. Analysis of Limits on CCM Usage + B.1. Confidentiality Limits + B.2. Integrity Limits + B.3. Limits for AEAD_AES_128_CCM_8 + Appendix C. Implementation Pitfalls + Contributors + Authors' Addresses + +1. Introduction + + The primary goal of the TLS protocol is to establish an + authenticated, confidentiality- and integrity-protected channel + between two communicating peers. The TLS protocol is composed of two + layers: the TLS record protocol and the TLS handshake protocol. + However, TLS must run over a reliable transport channel -- typically + TCP [RFC0793]. + + There are applications that use UDP [RFC0768] as a transport and the + Datagram Transport Layer Security (DTLS) protocol has been developed + to offer communication security protection for those applications. + DTLS is deliberately designed to be as similar to TLS as possible, + both to minimize new security invention and to maximize the amount of + code and infrastructure reuse. + + DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 + [RFC4346], and DTLS 1.2 [RFC6347] was defined as a series of deltas + to TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was + skipped in order to harmonize version numbers with TLS. This + specification describes the most current version of the DTLS protocol + as a delta from TLS 1.3 [TLS13]. It obsoletes DTLS 1.2. + + Implementations that speak both DTLS 1.2 and DTLS 1.3 can + interoperate with those that speak only DTLS 1.2 (using DTLS 1.2 of + course), just as TLS 1.3 implementations can interoperate with TLS + 1.2 (see Appendix D of [TLS13] for details). While backwards + compatibility with DTLS 1.0 is possible, the use of DTLS 1.0 is not + recommended, as explained in Section 3.1.2 of [RFC7525]. [DEPRECATE] + forbids the use of DTLS 1.0. + +2. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The following terms are used: + + client: The endpoint initiating the DTLS connection. + + association: Shared state between two endpoints established with a + 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 + establishes the parameters of the connection. + + peer: An endpoint. When discussing a particular endpoint, "peer" + refers to the 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. + + The reader is assumed to be familiar with [TLS13]. As in TLS 1.3, + the HelloRetryRequest has the same format as a ServerHello message, + but for convenience we use the term HelloRetryRequest throughout this + document as if it were a distinct message. + + DTLS 1.3 uses network byte order (big-endian) format for encoding + messages based on the encoding format defined in [TLS13] and earlier + (D)TLS specifications. + + The reader is also assumed to be familiar with [RFC9146], as this + document applies the CID functionality to DTLS 1.3. + + Figures in this document illustrate various combinations of the DTLS + protocol exchanges, and the symbols have the following meaning: + + '+' 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. + +3. DTLS Design Rationale and Overview + + The basic design philosophy of DTLS is to construct "TLS over + datagram transport". Datagram transport neither requires nor + provides reliable or in-order delivery of data. The DTLS protocol + preserves this property for application data. Applications such as + media streaming, Internet telephony, and online gaming use datagram + transport for communication due to the delay-sensitive nature of + transported data. The behavior of such applications is unchanged + when the DTLS protocol is used to secure communication, since the + DTLS protocol does not compensate for lost or reordered data traffic. + Note that while low-latency streaming and gaming use DTLS to protect + data (e.g., for protection of a WebRTC data channel), telephony + utilizes DTLS for key establishment and the Secure Real-time + Transport Protocol (SRTP) for protection of data [RFC5763]. + + TLS cannot be used directly over datagram transports for the + following four reasons: + + 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). + +3.1. Packet Loss + + DTLS uses a simple retransmission timer to handle packet loss. + Figure 1 demonstrates the basic concept, using the first phase of the + DTLS handshake: + + Client Server + ------ ------ + ClientHello ------> + + X<-- HelloRetryRequest + (lost) + + [Timer Expires] + + ClientHello ------> + (retransmit) + + Figure 1: DTLS Retransmission Example + + Once the client has transmitted the ClientHello message, it expects + to see a HelloRetryRequest or a ServerHello from the server. + However, if the timer expires, the client knows that either the + ClientHello or the response from the server has been lost, which + causes the client to 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 it + sends (other than HelloRetryRequest) and retransmits when that timer + expires. Not applying retransmissions to the HelloRetryRequest + avoids the need to create state on the server. The HelloRetryRequest + is designed to be small enough that it will not itself be fragmented, + thus avoiding concerns about interleaving multiple + HelloRetryRequests. + + For more detail on timeouts and retransmission, see Section 5.8. + +3.2. Reordering + + In DTLS, each handshake message is assigned a specific sequence + number. When a peer receives a handshake message, it can quickly + determine whether that message is the next message it expects. If it + is, then it processes it. If not, it queues it for future handling + once all previous messages have been received. + +3.3. Fragmentation + + TLS and DTLS handshake messages can be quite large (in theory up to + 2^24-1 bytes, in practice many kilobytes). By contrast, UDP + datagrams are often limited to less than 1500 bytes if IP + fragmentation is not desired. In order to compensate for this + limitation, each DTLS handshake message may be fragmented over + several DTLS records, each of which is intended to fit in a single + UDP datagram (see Section 4.4 for guidance). Each DTLS handshake + message contains both a fragment offset and a fragment length. Thus, + a recipient in possession of all bytes of a handshake message can + reassemble the original unfragmented message. + +3.4. Replay Detection + + DTLS optionally supports record replay detection. The technique used + is the same as in IPsec AH/ESP, by maintaining a bitmap window of + received records. Records that are too old to fit in the window and + records that have previously been received are silently discarded. + The replay detection feature is optional, since packet duplication is + not always malicious but can also occur due to routing errors. + Applications may conceivably detect duplicate packets and accordingly + modify their data transmission strategy. + +4. The DTLS Record Layer + + The DTLS 1.3 record layer is different from the TLS 1.3 record layer + and also different from the DTLS 1.2 record layer. + + 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. + + DTLSPlaintext records are used to send unprotected records and + DTLSCiphertext records are used to send protected records. + + The DTLS record formats are shown below. Unless explicitly stated + the meaning of the fields is unchanged from previous TLS/DTLS + versions. + + 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; + + Figure 2: DTLS 1.3 Record Formats + + legacy_record_version: This value MUST be set to {254, 253} for all + records other than 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) | + +-+-+-+-+-+-+-+-+ + + Figure 3: DTLS 1.3 Unified Header + + Fixed Bits: The three high bits of the first byte of the unified + header are set to 001. This ensures that the value will fit + within the DTLS region when multiplexing is performed as described + in [RFC7983]. It also ensures that distinguishing encrypted DTLS + 1.3 records from encrypted DTLS 1.2 records is possible when they + are carried on the same host/port quartet; such multiplexing is + only possible when CIDs [RFC9146] 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 functionality is + described in [RFC9146]. An example can be found in Section 9.1. + + Sequence Number: The low-order 8 or 16 bits of the record sequence + number. This value is 16 bits 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. + + As with previous versions of DTLS, multiple DTLSPlaintext and + DTLSCiphertext records can be included in the same underlying + transport datagram. + + Figure 4 illustrates different record headers. + + 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 + + Figure 4: DTLS 1.3 Header Examples + + The length field MAY be omitted by clearing the L bit, which means + that the record consumes the entire rest of the datagram in the lower + level transport. In this case, it is not possible to have multiple + DTLSCiphertext format records without length fields in the same + datagram. Omitting the length field MUST only be used for the last + record in a datagram. Implementations MAY mix records with and + without length fields on the same connection. + + If a Connection ID is negotiated, then it MUST be contained in all + datagrams. Sending implementations MUST NOT mix records from + multiple DTLS associations in the same datagram. If the second or + later record has a connection ID which does not correspond to the + same association used for previous records, the rest of the datagram + MUST be discarded. + + When expanded, the epoch and sequence number can be combined into an + unpacked RecordNumber structure, as shown below: + + struct { + uint64 epoch; + uint64 sequence_number; + } RecordNumber; + + This 128-bit value is used in the ACK message as well as in the + "record_sequence_number" input to the Authenticated Encryption with + Associated Data (AEAD) function. The entire header value shown in + Figure 4 (but prior to record number encryption; see Section 4.2.3) + is used as the additional data value for the AEAD function. For + instance, if the minimal variant is used, the Associated Data (AD) is + 2 octets long. Note that this design is different from the + additional data calculation for DTLS 1.2 and for DTLS 1.2 with + Connection IDs. In DTLS 1.3 the 64-bit sequence_number is used as + the sequence number for the AEAD computation; unlike DTLS 1.2, the + epoch is not included. + +4.1. Demultiplexing DTLS Records + + DTLS 1.3's header format is more complicated to demux than DTLS 1.2, + which always carried the content type as the first byte. As + described in Figure 5, the first byte determines how an incoming DTLS + record is demultiplexed. The first 3 bits of the first byte + distinguish a DTLS 1.3 encrypted record from record types used in + previous DTLS versions and plaintext DTLS 1.3 record types. Hence, + the range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded + from future allocations by IANA to avoid problems while + demultiplexing; see Section 14. Implementations can demultiplex DTLS + 1.3 records by examining the first byte as follows: + + * 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. + + 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 + +----------------+ + + Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records + +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 numbers are maintained separately for each epoch, with each + sequence_number initially being 0 for each epoch. + + The epoch number is initially zero and is incremented each time + keying material changes and a sender aims to rekey. More details are + provided in Section 6.1. + +4.2.1. Processing Guidelines + + Because DTLS records could be reordered, a record from epoch M may be + received after epoch N (where N > M) has begun. Implementations + SHOULD discard records from earlier epochs but MAY choose to retain + keying material from previous epochs for up to the default MSL + specified for TCP [RFC0793] to allow for packet reordering. (Note + that the intention here is that implementers use the current guidance + from the IETF for MSL, as specified in [RFC0793] or successors, not + that they attempt to interrogate the MSL that the system TCP stack is + using.) + + Conversely, it is possible for records that are protected with the + new epoch to be received prior to the completion of a handshake. For + instance, the server may send its Finished message and then start + transmitting data. Implementations MAY either buffer or discard such + records, though when DTLS is used over reliable transports (e.g., + SCTP [RFC4960]), they SHOULD be buffered and processed once the + handshake completes. Note that TLS's restrictions on when records + may be sent still apply, and the receiver treats the records as if + they were sent in the right order. + + Implementations MUST send retransmissions of lost messages using the + same epoch and keying material as the original transmission. + + Implementations MUST either abandon an association or rekey prior to + allowing the sequence number to wrap. + + Implementations MUST NOT allow the epoch to wrap, but instead MUST + establish a new association, terminating the old association. + +4.2.2. Reconstructing the Sequence Number and Epoch + + When receiving protected DTLS records, the recipient does not have a + full epoch or sequence number value in the record and so there is + some opportunity for ambiguity. Because the full sequence number is + used to compute the per-record nonce and the epoch determines the + keys, failure to reconstruct these values leads to failure to + deprotect the record, and so implementations MAY use a mechanism of + their choice to determine the full values. This section provides an + algorithm which is comparatively simple and which implementations are + RECOMMENDED to follow. + + If the epoch bits match those of the current epoch, then + implementations SHOULD reconstruct the sequence number by computing + the full sequence number which is numerically closest to one plus the + sequence number of the highest successfully deprotected record in the + current epoch. + + During the handshake phase, the epoch bits unambiguously indicate the + correct key to use. After the handshake is complete, if the epoch + bits do not match those from the current epoch, implementations + SHOULD use the most recent past epoch which has matching bits, and + then reconstruct the sequence number for that epoch as described + above. + +4.2.3. Record Number Encryption + + In DTLS 1.3, when records are encrypted, record sequence numbers are + also encrypted. The basic pattern is that the underlying encryption + algorithm used with the AEAD algorithm is used to generate a mask + which is then XORed with the sequence number. + + When the AEAD is based on AES, then the mask is generated by + computing AES-ECB on the first 16 bytes of the ciphertext: + + Mask = AES-ECB(sn_key, Ciphertext[0..15]) + + When the AEAD is based on ChaCha20, then the mask is generated by + treating the first 4 bytes of the ciphertext as the block counter and + the next 12 bytes as the nonce, passing them to the ChaCha20 block + function (Section 2.3 of [CHACHA]): + + Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) + + The sn_key is computed as follows: + + [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length) + + [sender] denotes the sending side. The per-epoch Secret value to be + used is described in Section 7.3 of [TLS13]. Note that a new key is + used for each epoch: because the epoch is sent in the clear, this + does not result in ambiguity. + + The encrypted sequence number is computed by XORing the leading bytes + of the mask with the on-the-wire representation of the sequence + number. Decryption is accomplished by the same process. + + This procedure requires the ciphertext length to be at least 16 + bytes. Receivers MUST reject shorter records as if they had failed + deprotection, as described in Section 4.5.2. Senders MUST pad short + plaintexts out (using the conventional record padding mechanism) in + order to make a suitable-length ciphertext. Note that most of the + DTLS AEAD algorithms have a 16 byte authentication tag and need no + padding. However, some algorithms, such as TLS_AES_128_CCM_8_SHA256, + have a shorter authentication tag and may require padding for short + inputs. + + Future cipher suites, which are not based on AES or ChaCha20, MUST + define their own record sequence number encryption in order to be + used with DTLS. + + Note that sequence number encryption is only applied to the + DTLSCiphertext structure and not to the DTLSPlaintext structure, even + though it also contains a sequence number. + +4.3. Transport Layer Mapping + + DTLS messages MAY be fragmented into multiple DTLS records. Each + DTLS record MUST fit within a single datagram. In order to avoid IP + fragmentation, clients of the DTLS record layer SHOULD attempt to + size records so that they fit within any Path MTU (PMTU) estimates + obtained from the record layer. For more information about PMTU + issues, see Section 4.4. + + Multiple DTLS records MAY be placed in a single datagram. Records + are encoded consecutively. The length field from DTLS records + containing that field can be used to determine the boundaries between + records. The final record in a datagram can omit the length field. + The first byte of the datagram payload MUST be the beginning of a + record. Records MUST NOT span datagrams. + + DTLS records without CIDs do not contain any association identifiers, + and applications must arrange to multiplex between associations. + With UDP, the host/port number is used to look up the appropriate + security association for incoming records without CIDs. + + Some transports, such as DCCP [RFC4340], provide their own sequence + numbers. When carried over those transports, both the DTLS and the + transport sequence numbers will be present. Although this introduces + a small amount of inefficiency, the transport layer and DTLS sequence + numbers serve different purposes; therefore, for conceptual + simplicity, it is superior to use both sequence numbers. + + Some transports provide congestion control for traffic carried over + them. If the congestion window is sufficiently narrow, DTLS + handshake retransmissions may be held rather than transmitted + immediately, potentially leading to timeouts and spurious + retransmission. When DTLS is used over such transports, care should + be 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 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 [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 layer + SHOULD behave as described below. + + If PMTU estimates are available from the underlying transport + protocol, they should be made available to upper layer protocols. In + particular: + + * 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. + + The DTLS record layer SHOULD also allow the upper layer protocol to + discover the amount of record expansion expected by the DTLS + processing; alternately, it MAY report PMTU estimates minus the + estimated expansion from the transport layer and DTLS record framing. + + Note that DTLS does not defend against spoofed ICMP messages; + implementations SHOULD ignore any such messages that indicate PMTUs + 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 a refusal to send the datagram as in + Section 14 of [RFC4340]), then the DTLS record layer MUST inform the + upper layer protocol of the error. + + The DTLS record layer SHOULD NOT interfere with upper layer protocols + performing PMTU discovery, whether via [RFC1191] and [RFC4821] for + IPv4 or via [RFC8201] for IPv6. In particular: + + * 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. + + The final issue is the DTLS handshake protocol. From the perspective + of the DTLS record layer, this is merely another upper layer + protocol. However, DTLS handshakes occur infrequently and involve + only a few round trips; therefore, the handshake protocol PMTU + handling places a premium on rapid completion over accurate PMTU + discovery. In order to allow connections under these circumstances, + DTLS implementations SHOULD follow the following rules: + + * 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. + +4.5. Record Payload Protection + + Like TLS, DTLS transmits data as a series of protected records. The + rest of this section describes the details of that format. + +4.5.1. Anti-Replay + + Each DTLS record contains a sequence number to provide replay + protection. Sequence number verification SHOULD be performed using + the following sliding window procedure, borrowed from Section 3.4.3 + of [RFC4303]. Because each epoch resets the sequence number space, a + separate sliding window is needed for each epoch. + + The received record counter for an epoch MUST be initialized to zero + when that epoch is first used. For each received record, the + receiver MUST verify that the record contains a sequence number that + does not duplicate the sequence number of any other record received + in that epoch during the lifetime of the association. This check + SHOULD happen after deprotecting the record; otherwise, the record + discard might itself serve as a timing channel for the record number. + Note that computing the full record number from the partial is still + a potential timing channel for the record number, though a less + powerful one than whether the record was deprotected. + + Duplicates are rejected through the use of a sliding receive window. + (How the window is implemented is a local matter, but the following + text describes the functionality that the implementation must + exhibit.) The receiver SHOULD pick a window large enough to handle + any plausible reordering, which depends on the data rate. (The + receiver does not notify the sender of the window size.) + + The "right" edge of the window represents the highest validated + sequence number value received in the epoch. Records that contain + sequence numbers lower than the "left" edge of the window are + rejected. Records falling within the window are checked against a + list of received records within the window. An efficient means for + performing this check, based on the use of a bit mask, is described + in Section 3.4.3 of [RFC4303]. If the received record falls within + the window and is new, or if the record is to the right of the + window, then the record is new. + + The window MUST NOT be updated due to a received record until that + record has been deprotected successfully. + +4.5.2. Handling Invalid Records + + Unlike TLS, DTLS is resilient in the face of invalid records (e.g., + invalid formatting, length, MAC, etc.). In general, invalid records + SHOULD be silently discarded, thus preserving the association; + however, an error MAY be logged for diagnostic purposes. + Implementations which choose to generate an alert instead MUST + generate fatal alerts to avoid attacks where the attacker repeatedly + probes the implementation to see how it responds to various types of + error. Note that if DTLS is run over UDP, then any implementation + which does this will be extremely susceptible to DoS attacks because + UDP forgery is so easy. Thus, generating fatal alerts is NOT + RECOMMENDED for such transports, both to increase the reliability of + DTLS service and to avoid the risk of spoofing attacks sending + traffic to unrelated third parties. + + If DTLS is being carried over a transport that is resistant to + forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts + because an attacker will have difficulty forging a datagram that will + not be rejected by the transport layer. + + Note that because invalid records are rejected at a layer lower than + the handshake state machine, they do not affect pending + retransmission timers. + +4.5.3. AEAD Limits + + Section 5.5 of [TLS13] defines limits on the number of records that + can be protected using the same keys. These limits are specific to + an AEAD algorithm and apply equally to DTLS. Implementations SHOULD + NOT protect more records than allowed by the limit specified for the + negotiated AEAD. Implementations SHOULD initiate a key update before + reaching this limit. + + [TLS13] does not specify a limit for AEAD_AES_128_CCM, but the + analysis in Appendix B shows that a limit of 2^23 packets can be used + to obtain the same confidentiality protection as the limits specified + in TLS. + + The usage limits defined in TLS 1.3 exist for protection against + attacks on confidentiality and apply to successful applications of + AEAD protection. The integrity protections in authenticated + encryption also depend on limiting the number of attempts to forge + packets. TLS achieves this by closing connections after any record + fails an authentication check. In comparison, DTLS ignores any + packet that cannot be authenticated, allowing multiple forgery + attempts. + + Implementations MUST count the number of received packets that fail + authentication with each key. If the number of packets that fail + authentication exceeds a limit that is specific to the AEAD in use, + an implementation SHOULD immediately close the connection. + Implementations SHOULD initiate a key update with update_requested + before reaching this limit. Once a key update has been initiated, + the previous keys can be dropped when the limit is reached rather + than closing the connection. Applying a limit reduces the + probability that an attacker is able to successfully forge a packet; + see [AEBounds] and [ROBUST]. + + For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, + the limit on the number of records that fail authentication is 2^36. + Note that the analysis in [AEBounds] supports a higher limit for + AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification + recommends a lower limit. For AEAD_AES_128_CCM, the limit on the + number of records that fail authentication is 2^23.5; see Appendix B. + + The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, + does not have a limit on the number of records that fail + authentication that both limits the probability of forgery by the + same amount and does not expose implementations to the risk of denial + of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256 + MUST NOT be used in DTLS without additional safeguards against + forgery. Implementations MUST set usage limits for + AEAD_AES_128_CCM_8 based on an understanding of any additional + forgery protections that are used. + + Any TLS cipher suite that is specified for use with DTLS MUST define + limits on the use of the associated AEAD function that preserves + margins for both confidentiality and integrity. That is, limits MUST + be specified for the number of packets that can be authenticated and + for the number of packets that can fail authentication before a key + update is required. Providing a reference to any analysis upon which + values are based -- and any assumptions used in that analysis -- + allows limits to be adapted to varying usage conditions. + +5. The DTLS Handshake Protocol + + DTLS 1.3 reuses the TLS 1.3 handshake messages and flows, with the + following changes: + + 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. + + In addition, DTLS reuses TLS 1.3's "cookie" extension to provide a + return-routability check as part of connection establishment. This + is an important DoS prevention mechanism for UDP-based protocols, + unlike TCP-based protocols, for which TCP establishes return- + routability as part of the connection establishment. + + DTLS implementations do not use the TLS 1.3 "compatibility mode" + described in Appendix D.4 of [TLS13]. DTLS servers MUST NOT echo the + "legacy_session_id" value from the client and endpoints MUST NOT send + ChangeCipherSpec messages. + + With these exceptions, the DTLS message formats, flows, and logic are + the same as those of TLS 1.3. + +5.1. Denial-of-Service Countermeasures + + Datagram security protocols are extremely susceptible to a variety of + DoS attacks. Two attacks are of particular concern: + + 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. + + In order to counter both of these attacks, DTLS borrows the stateless + cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When + the client sends its ClientHello message to the server, the server + MAY 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 client MUST send a new ClientHello with + the cookie added as an extension. The server then verifies the + cookie and proceeds with the handshake only if it is valid. This + mechanism forces the attacker/client to be able to receive the + cookie, which makes DoS attacks with spoofed IP addresses difficult. + This mechanism does not provide any defense against DoS attacks + mounted from valid IP addresses. + + The DTLS 1.3 specification changes how cookies are exchanged compared + to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest message and + conveys the cookie to the client via an extension. The client + receiving the cookie uses the same extension to place the 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 + ClientHello is present in DTLS 1.3 but is ignored by a DTLS + 1.3-compliant server implementation. + + The exchange is shown in Figure 6. Note that the figure focuses on + the cookie exchange; all other extensions are omitted. + + Client Server + ------ ------ + ClientHello ------> + + <----- HelloRetryRequest + + cookie + + ClientHello ------> + + cookie + + [Rest of handshake] + + Figure 6: DTLS Exchange with HelloRetryRequest Containing the + "cookie" Extension + + The "cookie" extension is defined in Section 4.2.2 of [TLS13]. When + sending the initial ClientHello, the client does not have a cookie + yet. In this case, the "cookie" extension is omitted and the + legacy_cookie field in the ClientHello message MUST be set to a zero- + length vector (i.e., a zero-valued single byte length field). + + When responding to a HelloRetryRequest, the client MUST create a new + ClientHello message following the description in Section 4.1.2 of + [TLS13]. + + If the HelloRetryRequest message is used, the initial ClientHello and + the HelloRetryRequest are included in the calculation of the + transcript hash. The computation of the message hash for the + HelloRetryRequest is done according to the description in + Section 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 + hash of the initial ClientHello (and HelloRetryRequest) to be stored + in the cookie. The initial ClientHello is included in the handshake + transcript as a synthetic "message_hash" message, so only the hash + value is needed for the handshake to complete, though the complete + HelloRetryRequest contents are needed. + + When the second ClientHello is received, the server can verify that + the cookie is valid and that the client can receive packets at the + given IP address. If the client's apparent IP address is embedded in + the cookie, this prevents an attacker from generating an acceptable + ClientHello apparently from another user. + + One potential attack on this scheme is for the attacker to collect a + number of cookies from different addresses where it controls + endpoints and then reuse them to attack the server. The server can + defend against this attack by changing the secret value frequently, + thus invalidating those cookies. If the server wishes to allow + legitimate clients to handshake through the transition (e.g., a + client received a cookie with Secret 1 and then sent the second + ClientHello after the server has changed to Secret 2), the server can + have a limited window during which it accepts both secrets. + [RFC7296] suggests adding a key identifier to cookies to detect this + case. An alternative approach is simply to try verifying with both + secrets. It is RECOMMENDED that servers implement a key rotation + scheme that allows the server to manage keys with overlapping + lifetimes. + + Alternatively, the server can store timestamps in the cookie and + reject cookies that were generated outside a certain interval of + time. + + DTLS servers SHOULD perform a cookie exchange whenever a new + handshake is being performed. If the server is being operated in an + environment where amplification is not a problem, e.g., where ICE + [RFC8445] has been used to establish bidirectional connectivity, the + server MAY be configured not to perform a cookie exchange. The + default SHOULD be that the exchange is performed, however. In + addition, the server MAY choose not to do a cookie exchange when a + session is resumed or, more generically, when the DTLS handshake uses + a PSK-based key exchange and 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 server SHOULD limit the + amount of data it sends toward a client address to three times the + amount of data sent by the client before it verifies that the client + is able to receive data at that address. A client address is valid + after a cookie exchange or handshake completion. Clients MUST be + prepared to do a cookie exchange with every handshake. Note that + cookies are only valid for the existing handshake and cannot be + stored for future handshakes. + + If a server receives a ClientHello with an invalid cookie, it MUST + terminate the handshake with an "illegal_parameter" alert. This + allows the client to restart the connection from scratch without a + cookie. + + As described in Section 4.1.4 of [TLS13], clients MUST abort the + handshake with an "unexpected_message" alert in response to 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 ID SHOULD + still offer the "connection_id" extension [RFC9146] unless there is + an application profile to the contrary. This permits a 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 DTLSHandshake messages, which + contain extra data needed to support message 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 original TLS + 1.3-style Handshake messages without the message_seq, + fragment_offset, and fragment_length values. Note that this is a + change from DTLS 1.2 where those values were included in the + transcript. + + The first message each side transmits in each association always has + message_seq = 0. Whenever a new message is generated, the + message_seq value is incremented by one. When a message is + retransmitted, the old message_seq value is reused, i.e., not + incremented. From the perspective of the DTLS record layer, the + retransmission is a new record. This record will have a new + DTLSPlaintext.sequence_number value. + + Note: In DTLS 1.2, the message_seq was reset to zero in case of a + rehandshake (i.e., renegotiation). On the surface, a rehandshake + in DTLS 1.2 shares 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 a retransmission from a previously + sent post-handshake message from a newly sent post-handshake + message. + + DTLS implementations maintain (at least notionally) a + next_receive_seq counter. This counter is initially set to zero. + When a handshake message is received, if its message_seq value + matches next_receive_seq, next_receive_seq is incremented and the + message is processed. If the sequence number is less than + next_receive_seq, the message MUST be discarded. If the sequence + number is greater than next_receive_seq, the implementation SHOULD + queue the message but MAY discard it. (This is a simple space/ + bandwidth trade-off). + + In addition to the handshake messages that are deprecated by the TLS + 1.3 specification, DTLS 1.3 furthermore deprecates the + HelloVerifyRequest message originally defined in DTLS 1.0. DTLS + 1.3-compliant implementations MUST NOT use the HelloVerifyRequest to + execute a return-routability check. A dual-stack DTLS 1.2 / DTLS 1.3 + client MUST, however, be prepared to interact with a DTLS 1.2 server. + +5.3. ClientHello Message + + The format of the ClientHello used by a DTLS 1.3 client differs from + the TLS 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 version negotiation and represented the highest version number + supported by the client. Experience has shown that many servers + do not properly implement version negotiation, leading to "version + intolerance" in which the server rejects an otherwise acceptable + ClientHello with a version number higher than it supports. In + DTLS 1.3, the client indicates its version preferences in the + "supported_versions" extension (see Section 4.2.1 of [TLS13]) and + the legacy_version field MUST be set to {254, 253}, which was the + version number for DTLS 1.2. The supported_versions entries for + DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire + versions). The value 0xfefc is used to indicate DTLS 1.3. + + random: Same as for TLS 1.3, except that the downgrade sentinels + described in Section 4.1.3 of [TLS13] when TLS 1.2 and 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 client which has a + cached session ID set by a pre-DTLS 1.3 server SHOULD set this + field 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. + +5.4. ServerHello Message + + The DTLS 1.3 ServerHello message is the same as the TLS 1.3 + ServerHello message, except that the legacy_version field is set to + 0xfefd, indicating DTLS 1.2. + +5.5. Handshake Message Fragmentation and Reassembly + + As described in Section 4.3, one or more handshake messages may be + carried in a single datagram. However, handshake messages are + potentially bigger than the size allowed by the underlying datagram + transport. DTLS provides a mechanism for fragmenting a handshake + message over a number of records, each of which can be transmitted in + separate datagrams, thus avoiding IP fragmentation. + + When transmitting the handshake message, the sender divides the + message into a series of N contiguous data ranges. The ranges MUST + NOT overlap. The sender then creates N DTLSHandshake messages, all + with the same message_seq value as the original DTLSHandshake + message. Each new message is labeled with the fragment_offset (the + number of bytes contained in previous fragments) and the + fragment_length (the length of this fragment). The length field in + all messages is the same as the length field of the original message. + An unfragmented message is a degenerate case with fragment_offset=0 + and fragment_length=length. Each handshake message fragment that is + placed into a record MUST be delivered in a single UDP datagram. + + When a DTLS implementation receives a handshake message fragment + corresponding to the next expected handshake message sequence number, + it MUST process it, either by buffering it until it has the entire + handshake message or by processing any in-order portions of the + message. The transcript consists of complete TLS Handshake messages + (reassembled as necessary). Note that this requires removing the + message_seq, fragment_offset, and fragment_length fields to create + the Handshake structure. + + DTLS implementations MUST be able to handle overlapping fragment + ranges. This allows senders to retransmit handshake messages with + smaller fragment sizes if the PMTU estimate changes. Senders MUST + NOT change handshake message bytes upon retransmission. Receivers + MAY check that retransmitted bytes are identical and SHOULD abort the + handshake with an "illegal_parameter" alert if the value of a byte + changes. + + Note that as with TLS, multiple handshake messages may be placed in + the same DTLS record, provided that there is room and that they are + part of the same flight. Thus, there are two acceptable ways to pack + two DTLS handshake messages into the same datagram: in the same + record or in separate records. + +5.6. EndOfEarlyData Message + + The DTLS 1.3 handshake has one important difference from the TLS 1.3 + handshake: the EndOfEarlyData message is omitted both from the wire + and the handshake transcript. Because DTLS records have epochs, + EndOfEarlyData is not necessary to determine when the early data is + complete, and because DTLS is lossy, attackers can trivially mount + the deletion attacks that EndOfEarlyData prevents in TLS. Servers + SHOULD 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. (See Section 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 the handshake message transmission of one peer + and ends with the expected response from the other peer. Table 1 + contains a complete list of message combinations that constitute + flights. + + +======+========+========+===================================+ + | Note | Client | Server | Handshake Messages | + +======+========+========+===================================+ + | | x | | ClientHello | + +------+--------+--------+-----------------------------------+ + | | | x | HelloRetryRequest | + +------+--------+--------+-----------------------------------+ + | | | x | ServerHello, EncryptedExtensions, | + | | | | CertificateRequest, Certificate, | + | | | | CertificateVerify, Finished | + +------+--------+--------+-----------------------------------+ + | 1 | x | | Certificate, CertificateVerify, | + | | | | Finished | + +------+--------+--------+-----------------------------------+ + | 1 | | x | NewSessionTicket | + +------+--------+--------+-----------------------------------+ + + Table 1: Flight Handshake Message Combinations + + 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] + + Figure 7: Message Flights for a Full DTLS Handshake (with Cookie + Exchange) + + 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] + + Figure 8: Message Flights for Resumption and PSK Handshake + (without Cookie Exchange) + + 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] + + Figure 9: Message Flights for the Zero-RTT Handshake + + Client Server + + +--------+ + <-------- [NewSessionTicket] | Flight | + +--------+ + + +--------+ + [ACK] --------> | Flight | + +--------+ + + Figure 10: Message Flights for the NewSessionTicket Message + + KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar + pattern to NewSessionTicket: a single message sent by one side + followed by an ACK by the other. + +5.8. Timeout and Retransmission + +5.8.1. State Machine + + DTLS uses a simple timeout and retransmission scheme with the state + machine shown in Figure 11. + + +-----------+ + | 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 + + Figure 11: DTLS Timeout and Retransmission State Machine + + The state machine has four basic states: PREPARING, SENDING, WAITING, + and FINISHED. + + In the PREPARING state, the implementation does whatever computations + are necessary to prepare the next flight of messages. It then + buffers them up for transmission (emptying the transmission buffer + first) and enters the SENDING state. + + In the SENDING state, the implementation transmits the buffered + flight of messages. If the implementation has received one or more + ACKs (see Section 7) from the peer, then it SHOULD omit any messages + or message fragments which have already been acknowledged. Once the + messages have been sent, the implementation then sets a retransmit + timer and enters the WAITING state. + + There are four ways to exit the WAITING state: + + 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. + + Because DTLS clients send the first message (ClientHello), they start + in the PREPARING state. DTLS servers start in the WAITING state, but + with empty buffers and no retransmit timer. + + In addition, for at least twice the default MSL defined for + [RFC0793], when in the FINISHED state, the server MUST respond to + retransmission of the client's final flight with a retransmit of its + ACK. + + Note that because of packet loss, it is possible for one side to be + sending application data even though the other side has not received + the first side's Finished message. Implementations MUST either + discard or buffer all application data records for epoch 3 and above + until they have received the Finished message from the peer. + Implementations MAY treat receipt of application data with a new + epoch prior to receipt of the corresponding Finished message as + evidence of reordering or packet loss and retransmit their final + flight immediately, shortcutting the retransmission timer. + +5.8.2. Timer Values + + The configuration of timer settings varies with implementations, and + certain deployment environments require timer value adjustments. + Mishandling of the timer can lead to serious congestion problems -- + for example, if many instances of a DTLS time out early and + retransmit too quickly on a congested link. + + Unless implementations have deployment-specific and/or external + information about the round trip time, implementations SHOULD use an + initial timer value of 1000 ms and double the value at each + retransmission, up to no less than 60 seconds (the maximum as + specified in RFC 6298 [RFC6298]). Application-specific profiles MAY + recommend shorter or longer timer values. For instance: + + * 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 [RFC5764], 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. + + In settings where there is external information (for instance, from + an ICE [RFC8445] handshake, or from previous connections to the same + server) about the RTT, implementations SHOULD use 1.5 times that RTT + estimate as the retransmit timer. + + Implementations SHOULD retain the current timer value until a message + is transmitted and acknowledged without having to be retransmitted, + at which time the value SHOULD be adjusted to 1.5 times the measured + round trip time for that message. After a long period of idleness, + no less than 10 times the current timer value, implementations MAY + reset the timer to the initial value. + + Note that because retransmission is for the handshake and not + dataflow, the effect on congestion of shorter timeouts is smaller + than in generic protocols such as TCP or QUIC. Experience with DTLS + 1.2, which uses a simpler "retransmit everything on timeout" + approach, has not shown serious congestion problems in practice. + +5.8.3. Large Flight Sizes + + DTLS does not have any built-in congestion control or rate control; + in general, this is not an issue because messages tend to be small. + However, in principle, some messages -- especially Certificate -- can + be quite large. If all the messages in a large flight are sent at + once, this can result in network congestion. A better strategy is to + send out only part of the flight, sending more when messages are + acknowledged. Several extensions have been standardized to reduce + the size of the Certificate message -- for example, the "cached_info" + extension [RFC7924]; certificate compression [RFC8879]; and + [RFC6066], which defines the "client_certificate_url" extension + allowing DTLS clients to send a sequence of Uniform Resource Locators + (URLs) instead of the client certificate. + + DTLS stacks SHOULD NOT send more than 10 records in a single + transmission. + +5.8.4. State Machine Duplication for Post-Handshake Messages + + DTLS 1.3 makes use of the following categories of post-handshake + messages: + + 1. NewSessionTicket + + 2. KeyUpdate + + 3. NewConnectionId + + 4. RequestConnectionId + + 5. Post-handshake client authentication + + Messages of each category can be sent independently, and reliability + is established via independent state machines, each of which behaves + as described in Section 5.8.1. For example, if a server sends a + NewSessionTicket and a CertificateRequest message, two independent + state machines will be created. + + Sending multiple instances of messages of a given category without + having completed earlier transmissions is allowed for some + categories, but not for others. Specifically, a server MAY send + multiple NewSessionTicket messages at once without awaiting ACKs for + earlier NewSessionTicket messages first. Likewise, a server MAY send + multiple CertificateRequest messages at once without having completed + earlier client authentication requests before. In contrast, + implementations MUST NOT send KeyUpdate, NewConnectionId, or + RequestConnectionId messages if an earlier message of the same type + has not yet been acknowledged. + + Note: Except for post-handshake client authentication, which + involves handshake messages in both directions, post-handshake + messages are single-flight, and their respective state machines on + the sender side reduce to waiting for an ACK and retransmitting + the original message. In particular, note that a + RequestConnectionId message does not force the receiver to send a + NewConnectionId message in reply, and both messages are therefore + treated independently. + + Creating and correctly updating multiple state machines requires + feedback from the handshake logic to the state machine layer, + indicating which message belongs to which state machine. For + example, if a server sends multiple CertificateRequest messages and + receives a Certificate message in response, the corresponding state + machine can only be determined after inspecting the + certificate_request_context field. Similarly, a server sending a + single CertificateRequest and receiving a NewConnectionId message in + response can only decide that the NewConnectionId message should be + treated through an independent state machine after inspecting the + handshake message type. + +5.9. Cryptographic Label Prefix + + Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label + prefix of "tls13 ". For DTLS 1.3, that label SHALL be "dtls13". + This ensures key separation between DTLS 1.3 and TLS 1.3. Note that + there is no trailing space; this is necessary in order to keep the + overall label size inside of one hash iteration because "DTLS" is one + letter longer than "TLS". + +5.10. Alert Messages + + Note that alert messages are not retransmitted at all, even when they + occur in the context of a handshake. However, a DTLS implementation + which would ordinarily issue an alert SHOULD generate a new alert + message if the offending record is received again (e.g., as a + retransmitted handshake message). Implementations SHOULD detect when + a peer is persistently sending bad messages and terminate the local + connection state after such misbehavior is detected. Note that + alerts are not reliably transmitted; implementations SHOULD NOT + depend on receiving alerts in order to signal errors or connection + closure. + + Any data received with an epoch/sequence number pair after that of a + valid received closure alert MUST be ignored. Note: this is a change + from TLS 1.3 which depends on the order of receipt 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 that + repeated connections happen on the same host/port quartet, then it is + possible that a client will silently abandon one connection and then + initiate another with the same parameters (e.g., after a reboot). + This will appear to the server as a new handshake with epoch=0. In + cases where a server believes it has an existing association on a + given host/port quartet and it receives an epoch=0 ClientHello, it + SHOULD proceed with a new handshake but MUST NOT destroy the existing + association until the client has demonstrated reachability either by + completing a cookie exchange or by completing a complete handshake + including delivering a verifiable Finished message. After a correct + Finished message is received, the server MUST abandon the previous + association to avoid confusion between two valid associations with + overlapping epochs. The reachability requirement prevents off-path/ + blind attackers from destroying associations merely by sending forged + ClientHellos. + + Note: It is not always possible to distinguish which association a + given record is from. For instance, if the client performs a + handshake, abandons the connection, and then immediately starts a + new handshake, it may not be possible to tell which connection a + given protected record is for. In these cases, trial decryption + may be necessary, though implementations could use CIDs to avoid + the 5-tuple-based ambiguity. + +6. Example of Handshake with Timeout and Retransmission + + The following is an example of a handshake with lost packets and + retransmissions. Note that the client sends an empty ACK message + because it can only acknowledge Record 2 sent by the server once it + has processed messages in Record 0 needed to establish epoch 2 keys, + which are needed to encrypt or decrypt messages found in Record 2. + Section 7 provides the necessary background details for this + interaction. Note: For simplicity, we are not resetting record + numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0", + etc. + + Client Server + ------ ------ + + Record 0 --------> + ClientHello + (message_seq=0) + + X<----- Record 0 + (lost) ServerHello + (message_seq=0) + Record 1 + EncryptedExtensions + (message_seq=1) + Certificate + (message_seq=2) + + + <-------- Record 2 + CertificateVerify + (message_seq=3) + Finished + (message_seq=4) + + Record 1 --------> + ACK [] + + + <-------- Record 3 + ServerHello + (message_seq=0) + EncryptedExtensions + (message_seq=1) + Certificate + (message_seq=2) + + <-------- Record 4 + CertificateVerify + (message_seq=3) + Finished + (message_seq=4) + + + Record 2 --------> + Certificate + (message_seq=1) + CertificateVerify + (message_seq=2) + Finished + (message_seq=3) + + <-------- Record 5 + ACK [2] + + Figure 12: Example DTLS Exchange Illustrating Message Loss + +6.1. Epoch Values and Rekeying + + A recipient of a DTLS message needs to select the correct keying + material in order to process an incoming message. With the + possibility of message loss and reordering, an identifier is needed + to determine which cipher state has been used to protect the record + payload. The epoch value fulfills this role in DTLS. In addition to + the TLS 1.3-defined key derivation steps (see Section 7 of [TLS13]), + a sender may want to rekey at any time during the lifetime of the + connection. It therefore needs to indicate that it is updating its + sending cryptographic keys. + + This version of DTLS assigns dedicated epoch values to messages in + the protocol exchange to allow identification of the correct cipher + state: + + * 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). + + Using these reserved epoch values, a receiver knows what cipher state + has been used to encrypt and integrity protect a message. + Implementations that receive a record with an epoch value for which + no corresponding cipher state can be determined SHOULD handle it as a + record which fails deprotection. + + Note that epoch values do not wrap. If a DTLS implementation would + need to wrap the epoch value, it MUST terminate the connection. + + The traffic key calculation is described in Section 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) + + Figure 13: Example DTLS Exchange with Epoch Information + +7. ACK Message + + The ACK message is used by an endpoint to indicate which handshake + records it has received and processed from the other side. ACK is + not a handshake message but is rather a separate content type, with + code point 26. This avoids having ACK being added to the handshake + transcript. Note that ACKs can still be sent in the same UDP + datagram as handshake records. + + struct { + RecordNumber record_numbers<0..2^16-1>; + } ACK; + + record_numbers: A list of the records containing handshake messages + in the current flight which the endpoint has received and either + processed or buffered, in numerically increasing order. + + Implementations MUST NOT acknowledge records containing handshake + messages or fragments which have not been processed or buffered. + Otherwise, deadlock can ensue. As an example, implementations MUST + NOT send ACKs for handshake messages which they discard because they + are not the next expected message. + + During the handshake, ACKs only cover the current outstanding flight + (this is possible because DTLS is generally a lock-step protocol). + In particular, receiving a message from a handshake flight implicitly + acknowledges all messages from the previous flight(s). Accordingly, + an ACK from the server would not cover both the ClientHello and the + client's Certificate message, because the ClientHello and client + Certificate are in different flights. Implementations can accomplish + this by clearing their ACK list upon receiving the start of the next + flight. + + For post-handshake messages, ACKs SHOULD be sent once for each + received and processed handshake record (potentially subject to some + delay) and MAY cover more than one flight. This includes records + containing messages which are discarded because a previous copy has + been received. + + During the handshake, ACK records MUST be sent with an epoch which is + equal to or higher than the record which is being acknowledged. Note + that some care is required when processing flights spanning multiple + epochs. For instance, if the client receives only the ServerHello + and Certificate and wishes to ACK them in a single record, it must do + so in epoch 2, as it is required to use an epoch greater than or + equal to 2 and cannot yet send with any greater epoch. + Implementations SHOULD simply use the highest current sending epoch, + which will generally be the highest available. After the handshake, + implementations MUST use the highest available sending epoch. + +7.1. Sending ACKs + + When an implementation detects a disruption in the receipt of the + current incoming flight, it SHOULD generate an ACK that covers the + messages from that flight which it has received and processed so far. + Implementations have some discretion about which events to treat as + signs of disruption, but it is RECOMMENDED that they generate ACKs + 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 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 + ([RFC9002], Section 6.1.2) work out to a delay of about 1/3 of the + retransmit timer. + + In general, flights MUST be ACKed unless they are implicitly + acknowledged. In the present specification, the following flights + are implicitly acknowledged by the receipt of the next flight, which + generally immediately follows the flight: + + 1. Handshake flights other than the client's final flight of the + main handshake. + + 2. The server's post-handshake CertificateRequest. + + ACKs SHOULD NOT be sent for these flights unless the responding + flight cannot be generated immediately. All other flights MUST be + ACKed. In this case, implementations MAY send explicit ACKs for the + complete received flight even though it will eventually also be + implicitly acknowledged through the responding flight. A notable + example for this is the case of client authentication in constrained + environments, where generating the CertificateVerify message can take + considerable time on the client. Implementations MAY acknowledge the + records corresponding to each transmission of each flight or simply + acknowledge the most recent one. In general, implementations SHOULD + ACK as many received packets as can fit into the ACK record, as this + provides the most complete information and thus reduces the chance of + spurious retransmission; if space is limited, implementations SHOULD + favor including records which have not yet been acknowledged. + + Note: While some post-handshake messages follow a request/response + pattern, this does not necessarily imply receipt. For example, a + KeyUpdate sent in response to a KeyUpdate with request_update set + to "update_requested" does not implicitly acknowledge the earlier + KeyUpdate message because the two KeyUpdate messages might have + crossed in flight. + + ACKs MUST NOT be sent for records of any content type other than + handshake or for records which cannot be deprotected. + + Note that in some cases it may be necessary to send an ACK which does + not contain any record numbers. For instance, a client might receive + an EncryptedExtensions message prior to receiving a ServerHello. + Because it cannot decrypt the EncryptedExtensions, it cannot safely + acknowledge it (as it might be damaged). If the client does not send + an ACK, the server will eventually retransmit its first flight, but + this might take far longer than the actual round trip time between + client and server. Having the client send an empty ACK shortcuts + this process. + +7.2. Receiving ACKs + + When an implementation receives an ACK, it SHOULD record that the + messages or message fragments sent in the records being ACKed were + received and omit them from any future retransmissions. Upon receipt + of an ACK that leaves it with only some messages from a flight having + been acknowledged, an implementation SHOULD retransmit the + unacknowledged messages or fragments. Note that this requires + implementations to track which messages appear in which records. + Once all the messages in a flight have been acknowledged, the + implementation MUST cancel all retransmissions of that flight. + Implementations MUST treat a record as having been acknowledged if it + appears in any ACK; this prevents spurious retransmission in cases + where a flight is very large and the receiver is forced to elide + acknowledgements for records which have already been ACKed. As noted + above, the receipt of any record responding to a given flight MUST be + taken as an implicit acknowledgement for the entire flight 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 deployments with lossy networks, such + as low-power, long-range radio networks as well as low-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 the protocol. For instance, the ACK message sent by + the client in Figure 13 acknowledges receipt and processing of Record + 4 (containing the NewSessionTicket message), and if it is not sent, + the server will continue retransmission of the NewSessionTicket + indefinitely until its maximum retransmission count is reached. + +8. Key Updates + + As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to + indicate that they are updating their sending keys. As with other + handshake messages with no built-in response, KeyUpdates MUST be + acknowledged. In order to facilitate epoch reconstruction + (Section 4.2.2), implementations MUST NOT send records with the new + keys or send a new KeyUpdate until the previous KeyUpdate has been + acknowledged (this avoids having too many epochs in active use). + + Due to loss and/or reordering, DTLS 1.3 implementations may receive a + record with an older epoch than the current one (the requirements + above preclude receiving a newer record). They SHOULD attempt to + process those records with that epoch (see Section 4.2.2 for + information on determining the correct epoch) but MAY opt to discard + such out-of-epoch records. + + Due to the possibility of an ACK message for a KeyUpdate being lost + and thereby preventing the sender of the KeyUpdate from updating its + keying material, receivers MUST retain the pre-update keying material + until receipt and successful decryption of a message using the new + keys. + + Figure 14 shows an example exchange illustrating that successful ACK + processing updates the keys of the KeyUpdate message sender, which is + reflected in the change of epoch values. + + Client Server + + /-------------------------------------------\ + | | + | Initial Handshake | + \-------------------------------------------/ + + + [Application Data] --------> + (epoch=3) + + <-------- [Application Data] + (epoch=3) + + /-------------------------------------------\ + | | + | Some time later ... | + \-------------------------------------------/ + + + [Application Data] --------> + (epoch=3) + + + [KeyUpdate] + (+ update_requested --------> + (epoch 3) + + + <-------- [Application Data] + (epoch=3) + + + [ACK] + <-------- (epoch=3) + + + [Application Data] + (epoch=4) --------> + + + + <-------- [KeyUpdate] + (epoch=3) + + + [ACK] --------> + (epoch=4) + + + <-------- [Application Data] + (epoch=4) + + Figure 14: Example DTLS Key Update + + With a 128-bit key as in AES-128, rekeying 2^64 times has a high + probability of key reuse within a given connection. Note that even + if the key repeats, the IV is also independently generated. In order + to provide an extra margin of security, sending implementations MUST + NOT allow the epoch to exceed 2^48-1. In order to allow this value + to be changed later, receiving implementations MUST NOT enforce this + rule. If a sending implementation receives a KeyUpdate with + request_update set to "update_requested", it MUST NOT send its own + KeyUpdate if that would cause it to exceed these limits and SHOULD + instead ignore the "update_requested" flag. Note: this overrides the + requirement in TLS 1.3 to always send a KeyUpdate in response to + "update_requested". + +9. Connection ID Updates + + If the client and server have negotiated the "connection_id" + extension [RFC9146], either side can send a new CID that it wishes + the other side to use in a NewConnectionId message. + + 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 + are spare. If usage is set to "cid_immediate", then one of the + new CIDs MUST be used immediately for all future records. If it + is set to "cid_spare", then either an existing or new CID MAY be + used. + + Endpoints SHOULD use receiver-provided CIDs in the order they were + provided. Implementations which receive more spare CIDs than they + wish to maintain MAY simply discard any extra CIDs. Endpoints MUST + NOT have more than one NewConnectionId message outstanding. + + Implementations which either did not negotiate the "connection_id" + extension or which have negotiated receiving an empty CID MUST NOT + send NewConnectionId. Implementations MUST NOT send + RequestConnectionId when sending an empty Connection ID. + Implementations which detect a violation of these rules MUST + terminate the connection with an "unexpected_message" alert. + + Implementations SHOULD use a new CID whenever sending on a new path + and SHOULD request new CIDs for this purpose if path changes are + anticipated. + + struct { + uint8 num_cids; + } RequestConnectionId; + + num_cids: The number of CIDs desired. + + Endpoints SHOULD respond to RequestConnectionId by sending a + NewConnectionId with usage "cid_spare" containing num_cids CIDs as + soon as possible. Endpoints MUST NOT send a RequestConnectionId + message when an existing request is still unfulfilled; this implies + that endpoints need to request new CIDs well in advance. An endpoint + MAY handle requests which it considers excessive by responding with a + NewConnectionId message containing fewer than num_cids CIDs, + including no CIDs at all. Endpoints MAY handle an excessive number + of RequestConnectionId messages by terminating the connection using a + "too_many_cids_requested" (alert number 52) alert. + + Endpoints MUST NOT send either of these messages if they did not + negotiate a CID. If an implementation receives these messages when + CIDs were not negotiated, it MUST abort the connection with an + "unexpected_message" alert. + +9.1. Connection ID Example + + Below is an example exchange for DTLS 1.3 using a single CID 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) + + Figure 15: Example DTLS 1.3 Exchange with CIDs + + If no CID is negotiated, then the receiver MUST reject any records it + receives that contain a CID. + +10. Application Data Protocol + + Application data messages are carried by the record layer and are + split into records and encrypted based on the current connection + state. The messages are treated as transparent data to the record + layer. + +11. Security Considerations + + Security issues are discussed primarily in [TLS13]. + + The primary additional security consideration raised by DTLS is that + of denial of service by excessive resource consumption. DTLS + includes a cookie exchange designed to protect against denial of + service. However, implementations that do not use this cookie + exchange are still vulnerable to DoS. In particular, DTLS servers + that do not use the cookie exchange may be used as attack amplifiers + even if they themselves are not experiencing DoS. Therefore, DTLS + servers SHOULD use the cookie exchange unless there is good reason to + believe that amplification is not a threat in their environment. + Clients MUST be prepared to do a cookie exchange with every + handshake. + + Some key properties required of the cookie for the cookie-exchange + mechanism to be functional are described in Section 3.3 of [RFC2522]: + + * 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. + + Although the cookie must allow the server to produce the right + handshake transcript, it SHOULD be constructed so that knowledge of + the cookie is insufficient to reproduce the ClientHello contents. + Otherwise, this may create problems with future extensions such as + Encrypted Client Hello [TLS-ECH]. + + When cookies are generated using a keyed authentication mechanism, it + should be possible to rotate the associated secret key, so that + temporary compromise of the key does not permanently compromise the + integrity of the cookie-exchange mechanism. Though this secret is + not as high-value as, e.g., a session-ticket-encryption key, rotating + the cookie-generation key on a similar timescale would ensure that + the key rotation functionality is exercised regularly and thus in + working order. + + The cookie exchange provides address validation during the initial + handshake. DTLS with Connection IDs allows for endpoint addresses to + change during the association; any such updated addresses are not + covered by the cookie exchange during the handshake. DTLS + implementations MUST NOT update the address they send to in response + to packets from a different address unless they first perform some + reachability test; no such test is defined in this specification and + a future specification would need to specify a complete procedure for + how and when to update addresses. Even with such a test, an active + on-path adversary can also black-hole traffic or create a reflection + attack against third parties because a DTLS peer has no means to + distinguish a genuine address update event (for example, due to a NAT + rebinding) from one that is malicious. This attack is of concern + when there is a large asymmetry of request/response message sizes. + + With the exception of order protection and non-replayability, the + security guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS + always provides order protection and non-replayability, DTLS does not + provide order protection and may not provide replay protection. + + Unlike TLS implementations, DTLS implementations SHOULD NOT respond + to invalid records by terminating the connection. + + TLS 1.3 requires replay protection for 0-RTT data (or rather, for + connections that use 0-RTT data; see Section 8 of [TLS13]). DTLS + provides an optional per-record replay-protection mechanism, since + datagram protocols are inherently subject to message reordering and + replay. These two replay-protection mechanisms are orthogonal, and + neither mechanism meets the requirements for the other. + + DTLS 1.3's handshake transcript does not include the new DTLS fields, + which makes it have the same format as TLS 1.3. However, the DTLS + 1.3 and TLS 1.3 transcripts are disjoint because they use different + version numbers. Additionally, the DTLS 1.3 key schedule uses a + different label and so will produce different keys for the same + transcript. + + The security and privacy properties of the CID for DTLS 1.3 build on + top of what is described for DTLS 1.2 in [RFC9146]. There are, + however, several differences: + + * 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. + +12. Changes since DTLS 1.2 + + Since TLS 1.3 introduces a large number of changes with respect to + TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally + large. For this reason, this section focuses on the most important + changes only. + + * 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. + +13. Updates Affecting DTLS 1.2 + + This document defines several changes that optionally affect + implementations of DTLS 1.2, including those which do not also + support DTLS 1.3. + + * 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. + +14. IANA Considerations + + IANA has allocated the content type value 26 in the "TLS ContentType" + registry for the ACK message, defined in Section 7. The value for + the "DTLS-OK" column is "Y". IANA has reserved the content type + range 32-63 so that content types in this range are not allocated. + + IANA has allocated value 52 for the "too_many_cids_requested" alert + in the "TLS Alerts" registry. The value for the "DTLS-OK" column is + "Y". + + IANA has allocated two values in the "TLS HandshakeType" registry, + defined in [TLS13], for request_connection_id (9) and + new_connection_id (10), as defined in this document. The value for + the "DTLS-OK" column is "Y". + + IANA has added this RFC as a reference to the "TLS Cipher Suites" + registry along with the following Note: + + | Any TLS cipher suite that is specified for use with DTLS MUST + | define limits on the use of the associated AEAD function that + | preserves margins for both confidentiality and integrity, as + | specified in Section 4.5.3 of RFC 9147. + +15. References + +15.1. Normative References + + [CHACHA] Nir, Y. 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] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + <https://www.rfc-editor.org/info/rfc768>. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + <https://www.rfc-editor.org/info/rfc793>. + + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + DOI 10.17487/RFC1191, November 1990, + <https://www.rfc-editor.org/info/rfc1191>. + + [RFC2119] Bradner, S., "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] Conta, A., Deering, S., and M. Gupta, Ed., "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] Mathis, M. and J. Heffner, "Packetization Layer Path MTU + Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, + <https://www.rfc-editor.org/info/rfc4821>. + + [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, + "Computing TCP's Retransmission Timer", RFC 6298, + DOI 10.17487/RFC6298, June 2011, + <https://www.rfc-editor.org/info/rfc6298>. + + [RFC8174] Leiba, B., "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] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., 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] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + +15.2. Informative References + + [AEAD-LIMITS] + Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on + AEAD Algorithms", Work in Progress, Internet-Draft, draft- + irtf-cfrg-aead-limits-04, 7 March 2022, + <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- + aead-limits-04>. + + [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated + Encryption Use in TLS", 28 August 2017, + <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. + + [CCM-ANALYSIS] + Jonsson, J., "On the Security of CTR + CBC-MAC", Selected + Areas in Cryptography pp. 76-93, + DOI 10.1007/3-540-36492-7_7, February 2003, + <https://doi.org/10.1007/3-540-36492-7_7>. + + [DEPRECATE] + Moriarty, K. 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] + Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for + the Internet of Things", Work in Progress, Internet-Draft, + draft-ietf-uta-tls13-iot-profile-04, 7 March 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-uta- + tls13-iot-profile-04>. + + [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management + Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, + <https://www.rfc-editor.org/info/rfc2522>. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + <https://www.rfc-editor.org/info/rfc4303>. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + DOI 10.17487/RFC4340, March 2006, + <https://www.rfc-editor.org/info/rfc4340>. + + [RFC4346] Dierks, T. 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] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, + <https://www.rfc-editor.org/info/rfc4347>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5238] Phelan, T., "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] Dierks, T. 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] Fischl, J., Tschofenig, H., 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] McGrew, D. 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] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + DOI 10.17487/RFC6066, January 2011, + <https://www.rfc-editor.org/info/rfc6066>. + + [RFC6347] Rescorla, E. 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] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., 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] Sheffer, Y., Holz, R., 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] Santesson, S. 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] Petit-Huguenin, M. 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] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., + "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] Keranen, A., Holmberg, C., 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] Ghedini, A. and V. Vasiliev, "TLS Certificate + Compression", RFC 8879, DOI 10.17487/RFC8879, December + 2020, <https://www.rfc-editor.org/info/rfc8879>. + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection + and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, + May 2021, <https://www.rfc-editor.org/info/rfc9002>. + + [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust + Channels: Handling Unreliable Networks in the Record + Layers of QUIC and DTLS 1.3", received 15 June 2020, last + revised 22 February 2021, + <https://eprint.iacr.org/2020/718>. + + [TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C.A. Wood, "TLS + Encrypted Client Hello", Work in Progress, Internet-Draft, + draft-ietf-tls-esni-14, 13 February 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-tls- + esni-14>. + +Appendix A. Protocol Data Structures and Constant Values + + This section provides the normative protocol types and constants + definitions. + +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; + +Appendix B. Analysis of Limits on CCM Usage + + TLS [TLS13] and [AEBounds] do not specify limits on key usage for + AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires + limits on use that ensure that both confidentiality and integrity are + preserved. This section documents that analysis for + AEAD_AES_128_CCM. + + [CCM-ANALYSIS] is used as the basis of this analysis. The results of + that analysis are used to derive usage limits that are based on those + chosen in [TLS13]. + + This analysis uses symbols for multiplication (*), division (/), and + exponentiation (^), plus parentheses for establishing precedence. + The following symbols are also used: + + 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 value is the bound on the number of packets that can be + protected before updating keys. + + v: The number of forged packets that endpoints will accept. This + value is the bound on the number of forged packets that an + endpoint can reject before updating keys. + + The analysis of AEAD_AES_128_CCM relies on a count of the number of + block operations involved in producing each message. For simplicity, + and to match the analysis of other AEAD functions in [AEBounds], this + analysis assumes a packet length of 2^10 blocks and a packet size + limit of 2^14 bytes. + + For AEAD_AES_128_CCM, the total number of block cipher operations is + the sum of: the length of the associated data in blocks, the length + of the ciphertext in blocks, and the length of the plaintext in + blocks, plus 1. In this analysis, this is simplified to a value of + twice the maximum length of a record in blocks (that is, 2l = 2^11). + This simplification is based on the associated data being limited to + one block. + +B.1. Confidentiality Limits + + For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an + attacker gains a distinguishing advantage over an ideal pseudorandom + permutation (PRP) of no 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 of keys without causing an attacker to gain a larger + advantage than the target of 2^-60. + +B.2. Integrity Limits + + For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an + attacker gains 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 in + TLS 1.3, as summarized in [AEAD-LIMITS]. As t and n are both 128, + the first term is negligible relative to the second, so that term can + be removed without a significant effect on the result. This produces + the relation: + + v + q <= 2^24.5 + + Using the previously established value of 2^23 for q and rounding, + this leads to an upper limit on v of 2^23.5. That is, endpoints + cannot attempt to authenticate more than 2^23.5 packets with the same + set of keys without causing an 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 for AEAD_AES_128_CCM, as this does not depend on the tag + length; see Appendix B.1. + + The shorter tag length of 64 bits means that the simplification used + in Appendix B.2 does not apply to AEAD_AES_128_CCM_8. If the goal is + to preserve the same margins as other cipher suites, then the limit + on forgeries is largely dictated by the first term of the advantage + formula: + + v <= 2^7 + + As this represents attempts that fail authentication, applying this + limit might be feasible in some environments. However, applying this + limit in an implementation intended for general use exposes + connections to an inexpensive denial-of-service attack. + + This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not + suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256 + cannot be used without additional measures to prevent forgery of + records, or to mitigate the effect of forgeries. This might require + understanding the constraints that exist in a particular deployment + or application. For instance, it might be possible to set a + different target for the advantage an attacker gains based on an + understanding of the constraints imposed on a specific usage of DTLS. + +Appendix C. Implementation Pitfalls + + In addition to the aspects of TLS that have been a source of + interoperability and security problems (Appendix C.3 of [TLS13]), + DTLS presents a few new potential sources of issues, noted here. + + * 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? + +Contributors + + Many people have contributed to previous DTLS versions, and they are + acknowledged in prior versions of DTLS specifications or in the + referenced specifications. + + Hanno Becker + Arm Limited + Email: Hanno.Becker@arm.com + + + David Benjamin + Google + Email: davidben@google.com + + + Thomas Fossati + Arm Limited + Email: thomas.fossati@arm.com + + + Tobias Gondrom + Huawei + Email: tobias.gondrom@gondrom.org + + + Felix Günther + ETH Zurich + Email: mail@felixguenther.info + + + Benjamin Kaduk + Akamai Technologies + Email: kaduk@mit.edu + + + Ilari Liusvaara + Independent + Email: ilariliusvaara@welho.com + + + Martin Thomson + Mozilla + Email: martin.thomson@gmail.com + + + Christopher A. Wood + Cloudflare + Email: caw@heapingbits.net + + + Yin Xinxing + Huawei + Email: yinxinxing@huawei.com + + + The sequence number encryption concept is taken from QUIC [RFC9000]. + We would like to thank the authors of RFC 9000 for their work. Felix + Günther and Martin Thomson contributed the analysis in Appendix B. + We would like to thank Jonathan Hammell, Bernard Aboba, and Andy + Cunningham for their review comments. + + Additionally, we would like to thank the IESG members for their + review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars + Eggert, Zaheduzzaman Sarker, John Scudder, Éric Vyncke, Robert + Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin + Vigoureux, and Alvaro Retana. + +Authors' Addresses + + Eric Rescorla + Mozilla + Email: ekr@rtfm.com + + + Hannes Tschofenig + Arm Limited + Email: hannes.tschofenig@arm.com + + + Nagendra Modadugu + Google, Inc. + Email: nagendra@cs.stanford.edu |