rfc9147.original   rfc9147.txt 
TLS E. Rescorla Internet Engineering Task Force (IETF) E. Rescorla
Internet-Draft RTFM, Inc. Request for Comments: 9147 Mozilla
Obsoletes: 6347 (if approved) H. Tschofenig Obsoletes: 6347 H. Tschofenig
Intended status: Standards Track Arm Limited Category: Standards Track Arm Limited
Expires: 1 November 2021 N. Modadugu ISSN: 2070-1721 N. Modadugu
Google, Inc. Google, Inc.
30 April 2021 March 2022
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
draft-ietf-tls-dtls13-43
Abstract Abstract
This document specifies Version 1.3 of the Datagram Transport Layer This document specifies version 1.3 of the Datagram Transport Layer
Security (DTLS) protocol. DTLS 1.3 allows client/server applications Security (DTLS) protocol. DTLS 1.3 allows client/server applications
to communicate over the Internet in a way that is designed to prevent to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery. eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is intentionally based on the Transport Layer The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)
Security (TLS) 1.3 protocol and provides equivalent security 1.3 protocol and provides equivalent security guarantees with the
guarantees with the exception of order protection/non-replayability. exception of order protection / non-replayability. Datagram
Datagram semantics of the underlying transport are preserved by the semantics of the underlying transport are preserved by the DTLS
DTLS protocol. protocol.
This document obsoletes RFC 6347. This document obsoletes RFC 6347.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 1 November 2021. 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. 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 This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology
3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 6 3. DTLS Design Rationale and Overview
3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Packet Loss
3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Reordering
3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Fragmentation
3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 8 3.4. Replay Detection
4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 8 4. The DTLS Record Layer
4.1. Demultiplexing DTLS Records . . . . . . . . . . . . . . . 12 4.1. Demultiplexing DTLS Records
4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 14 4.2. Sequence Number and Epoch
4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 14 4.2.1. Processing Guidelines
4.2.2. Reconstructing the Sequence Number and Epoch . . . . 15 4.2.2. Reconstructing the Sequence Number and Epoch
4.2.3. Record Number Encryption . . . . . . . . . . . . . . 15 4.2.3. Record Number Encryption
4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 16 4.3. Transport Layer Mapping
4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 17 4.4. PMTU Issues
4.5. Record Payload Protection . . . . . . . . . . . . . . . . 19 4.5. Record Payload Protection
4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 19 4.5.1. Anti-Replay
4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 20 4.5.2. Handling Invalid Records
4.5.3. AEAD Limits . . . . . . . . . . . . . . . . . . . . . 20 4.5.3. AEAD Limits
5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 22 5. The DTLS Handshake Protocol
5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 22 5.1. Denial-of-Service Countermeasures
5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 25 5.2. DTLS Handshake Message Format
5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 27 5.3. ClientHello Message
5.4. ServerHello Message . . . . . . . . . . . . . . . . . . . 28 5.4. ServerHello Message
5.5. Handshake Message Fragmentation and Reassembly . . . . . 28 5.5. Handshake Message Fragmentation and Reassembly
5.6. End Of Early Data . . . . . . . . . . . . . . . . . . . . 29 5.6. EndOfEarlyData Message
5.7. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 30 5.7. DTLS Handshake Flights
5.8. Timeout and Retransmission . . . . . . . . . . . . . . . 34 5.8. Timeout and Retransmission
5.8.1. State Machine . . . . . . . . . . . . . . . . . . . . 34 5.8.1. State Machine
5.8.2. Timer Values . . . . . . . . . . . . . . . . . . . . 37 5.8.2. Timer Values
5.8.3. Large Flight Sizes . . . . . . . . . . . . . . . . . 38 5.8.3. Large Flight Sizes
5.8.4. State machine duplication for post-handshake 5.8.4. State Machine Duplication for Post-Handshake Messages
messages . . . . . . . . . . . . . . . . . . . . . . 38 5.9. Cryptographic Label Prefix
5.9. CertificateVerify and Finished Messages . . . . . . . . . 40 5.10. Alert Messages
5.10. Cryptographic Label Prefix . . . . . . . . . . . . . . . 40 5.11. Establishing New Associations with Existing Parameters
5.11. Alert Messages . . . . . . . . . . . . . . . . . . . . . 40 6. Example of Handshake with Timeout and Retransmission
5.12. Establishing New Associations with Existing Parameters . 40 6.1. Epoch Values and Rekeying
6. Example of Handshake with Timeout and Retransmission . . . . 41 7. ACK Message
6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 42 7.1. Sending ACKs
7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Receiving ACKs
7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 46 7.3. Design Rationale
7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 47 8. Key Updates
7.3. Design Rationale . . . . . . . . . . . . . . . . . . . . 48 9. Connection ID Updates
8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. Connection ID Example
9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 50 10. Application Data Protocol
9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 51 11. Security Considerations
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 53 12. Changes since DTLS 1.2
11. Security Considerations . . . . . . . . . . . . . . . . . . . 53 13. Updates Affecting DTLS 1.2
12. Changes since DTLS 1.2 . . . . . . . . . . . . . . . . . . . 55 14. IANA Considerations
13. Updates affecting DTLS 1.2 . . . . . . . . . . . . . . . . . 56 15. References
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 15.1. Normative References
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 15.2. Informative References
15.1. Normative References . . . . . . . . . . . . . . . . . . 57 Appendix A. Protocol Data Structures and Constant Values
15.2. Informative References . . . . . . . . . . . . . . . . . 58 A.1. Record Layer
Appendix A. Protocol Data Structures and Constant Values . . . . 61 A.2. Handshake Protocol
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 61 A.3. ACKs
A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 62 A.4. Connection ID Management
A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Appendix B. Analysis of Limits on CCM Usage
A.4. Connection ID Management . . . . . . . . . . . . . . . . 64 B.1. Confidentiality Limits
Appendix B. Analysis of Limits on CCM Usage . . . . . . . . . . 64 B.2. Integrity Limits
B.1. Confidentiality Limits . . . . . . . . . . . . . . . . . 65 B.3. Limits for AEAD_AES_128_CCM_8
B.2. Integrity Limits . . . . . . . . . . . . . . . . . . . . 66 Appendix C. Implementation Pitfalls
B.3. Limits for AEAD_AES_128_CCM_8 . . . . . . . . . . . . . . 66 Contributors
Appendix C. Implementation Pitfalls . . . . . . . . . . . . . . 67 Authors' Addresses
Appendix D. History . . . . . . . . . . . . . . . . . . . . . . 67
Appendix E. Working Group Information . . . . . . . . . . . . . 70
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 70
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH
The source for this draft is maintained in GitHub. Suggested changes
should be submitted as pull requests at https://github.com/tlswg/
dtls13-spec. Instructions are on that page as well. Editorial
changes can be managed in GitHub, but any substantive change should
be discussed on the TLS mailing list.
The primary goal of the TLS protocol is to establish an The primary goal of the TLS protocol is to establish an
authenticated, confidentiality and integrity protected channel authenticated, confidentiality- and integrity-protected channel
between two communicating peers. The TLS protocol is composed of two between two communicating peers. The TLS protocol is composed of two
layers: the TLS Record Protocol and the TLS Handshake Protocol. layers: the TLS record protocol and the TLS handshake protocol.
However, TLS must run over a reliable transport channel - typically However, TLS must run over a reliable transport channel -- typically
TCP [RFC0793]. TCP [RFC0793].
There are applications that use UDP [RFC0768] as a transport and to There are applications that use UDP [RFC0768] as a transport and the
offer communication security protection for those applications the Datagram Transport Layer Security (DTLS) protocol has been developed
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, DTLS is deliberately designed to be as similar to TLS as possible,
both to minimize new security invention and to maximize the amount of both to minimize new security invention and to maximize the amount of
code and infrastructure reuse. code and infrastructure reuse.
DTLS 1.0 [RFC4347] was originally defined as a delta from TLS 1.1 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 [RFC4346], and DTLS 1.2 [RFC6347] was defined as a series of deltas
TLS 1.2 [RFC5246]. There is no DTLS 1.1; that version number was 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 skipped in order to harmonize version numbers with TLS. This
specification describes the most current version of the DTLS protocol specification describes the most current version of the DTLS protocol
as a delta from TLS 1.3 [TLS13]. It obsoletes DTLS 1.2. 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 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 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 course), just as TLS 1.3 implementations can interoperate with TLS
1.2 (see Appendix D of [TLS13] for details). While backwards 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 compatibility with DTLS 1.0 is possible, the use of DTLS 1.0 is not
recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525] and recommended, as explained in Section 3.1.2 of [RFC7525]. [DEPRECATE]
[DEPRECATE]. forbids the use of DTLS 1.0.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following terms are used: The following terms are used:
* client: The endpoint initiating the DTLS connection. client: The endpoint initiating the DTLS connection.
* association: Shared state between two endpoints established with a association: Shared state between two endpoints established with a
DTLS handshake. DTLS handshake.
* connection: Synonym for association. connection: Synonym for association.
* endpoint: Either the client or server of the connection. endpoint: Either the client or server of the connection.
* epoch: one set of cryptographic keys used for encryption and epoch: One set of cryptographic keys used for encryption and
decryption. decryption.
* handshake: An initial negotiation between client and server that handshake: An initial negotiation between client and server that
establishes the parameters of the connection. establishes the parameters of the connection.
* peer: An endpoint. When discussing a particular endpoint, "peer" peer: An endpoint. When discussing a particular endpoint, "peer"
refers to the endpoint that is remote to the primary subject of refers to the endpoint that is remote to the primary subject of
discussion. discussion.
* receiver: An endpoint that is receiving records. receiver: An endpoint that is receiving records.
* sender: An endpoint that is transmitting records. sender: An endpoint that is transmitting records.
* server: The endpoint which did not initiate the DTLS connection. server: The endpoint that did not initiate the DTLS connection.
* CID: Connection ID CID: Connection ID.
* MSL: Maximum Segment Lifetime MSL: Maximum Segment Lifetime.
The reader is assumed to be familiar with [TLS13]. As in TLS 1.3, The reader is assumed to be familiar with [TLS13]. As in TLS 1.3,
the HelloRetryRequest has the same format as a ServerHello message, the HelloRetryRequest has the same format as a ServerHello message,
but for convenience we use the term HelloRetryRequest throughout this but for convenience we use the term HelloRetryRequest throughout this
document as if it were a distinct message. document as if it were a distinct message.
DTLS 1.3 uses network byte order (big-endian) format for encoding DTLS 1.3 uses network byte order (big-endian) format for encoding
messages based on the encoding format defined in [TLS13] and earlier messages based on the encoding format defined in [TLS13] and earlier
(D)TLS specifications. (D)TLS specifications.
The reader is also assumed to be familiar with The reader is also assumed to be familiar with [RFC9146], as this
[I-D.ietf-tls-dtls-connection-id] as this document applies the CID document applies the CID functionality to DTLS 1.3.
functionality to DTLS 1.3.
Figures in this document illustrate various combinations of the DTLS Figures in this document illustrate various combinations of the DTLS
protocol exchanges and the symbols have the following meaning: protocol exchanges, and the symbols have the following meaning:
* '+' indicates noteworthy extensions sent in the previously noted '+' indicates noteworthy extensions sent in the previously noted
message. message.
* '*' indicates optional or situation-dependent messages/extensions '*' indicates optional or situation-dependent messages/extensions
that are not always sent. that are not always sent.
* '{}' indicates messages protected using keys derived from a '{}' indicates messages protected using keys derived from a
[sender]_handshake_traffic_secret. [sender]_handshake_traffic_secret.
* '[]' indicates messages protected using keys derived from '[]' indicates messages protected using keys derived from
traffic_secret_N. traffic_secret_N.
3. DTLS Design Rationale and Overview 3. DTLS Design Rationale and Overview
The basic design philosophy of DTLS is to construct "TLS over The basic design philosophy of DTLS is to construct "TLS over
datagram transport". Datagram transport does not require nor provide datagram transport". Datagram transport neither requires nor
reliable or in-order delivery of data. The DTLS protocol preserves provides reliable or in-order delivery of data. The DTLS protocol
this property for application data. Applications, such as media preserves this property for application data. Applications such as
streaming, Internet telephony, and online gaming use datagram media streaming, Internet telephony, and online gaming use datagram
transport for communication due to the delay-sensitive nature of transport for communication due to the delay-sensitive nature of
transported data. The behavior of such applications is unchanged transported data. The behavior of such applications is unchanged
when the DTLS protocol is used to secure communication, since the when the DTLS protocol is used to secure communication, since the
DTLS protocol does not compensate for lost or reordered data traffic. DTLS protocol does not compensate for lost or reordered data traffic.
Note that while low-latency streaming and gaming use DTLS to protect Note that while low-latency streaming and gaming use DTLS to protect
data (e.g. for protection of a WebRTC data channel), telephony data (e.g., for protection of a WebRTC data channel), telephony
utilizes DTLS for key establishment, and Secure Real-time Transport utilizes DTLS for key establishment and the Secure Real-time
Protocol (SRTP) for protection of data [RFC5763]. Transport Protocol (SRTP) for protection of data [RFC5763].
TLS cannot be used directly over datagram transports the following TLS cannot be used directly over datagram transports for the
five reasons: following four reasons:
1. TLS relies on an implicit sequence number on records. If a 1. TLS relies on an implicit sequence number on records. If a
record is not received, then the recipient will use the wrong record is not received, then the recipient will use the wrong
sequence number when attempting to remove record protection from sequence number when attempting to remove record protection from
subsequent records. DTLS solves this problem by adding sequence subsequent records. DTLS solves this problem by adding sequence
numbers to records. numbers to records.
2. The TLS handshake is a lock-step cryptographic protocol. 2. The TLS handshake is a lock-step cryptographic protocol.
Messages must be transmitted and received in a defined order; any Messages must be transmitted and received in a defined order; any
other order is an error. The DTLS handshake includes message other order is an error. The DTLS handshake includes message
sequence numbers to enable fragmented message reassembly and in- sequence numbers to enable fragmented message reassembly and in-
order delivery in case datagrams are lost or reordered. order delivery in case datagrams are lost or reordered.
3. During the handshake, messages are implicitly acknowledged by 3. Handshake messages are potentially larger than can be contained
other handshake messages. Some handshake messages, such as the
NewSessionTicket message, do not result in any direct response
that would allow the sender to detect loss. DTLS adds an
acknowledgment message to enable better loss recovery.
4. Handshake messages are potentially larger than can be contained
in a single datagram. DTLS adds fields to handshake messages to in a single datagram. DTLS adds fields to handshake messages to
support fragmentation and reassembly. support fragmentation and reassembly.
5. Datagram transport protocols, like UDP, are susceptible to 4. Datagram transport protocols are susceptible to abusive behavior
abusive behavior effecting denial of service attacks against effecting denial-of-service (DoS) attacks against
nonparticipants. DTLS adds a return-routability check and DTLS nonparticipants. DTLS adds a return-routability check and DTLS
1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1 1.3 uses the TLS 1.3 HelloRetryRequest message (see Section 5.1
for details). for details).
3.1. Packet Loss 3.1. Packet Loss
DTLS uses a simple retransmission timer to handle packet loss. DTLS uses a simple retransmission timer to handle packet loss.
Figure 1 demonstrates the basic concept, using the first phase of the Figure 1 demonstrates the basic concept, using the first phase of the
DTLS handshake: DTLS handshake:
skipping to change at page 7, line 33 skipping to change at line 291
ClientHello ------> ClientHello ------>
X<-- HelloRetryRequest X<-- HelloRetryRequest
(lost) (lost)
[Timer Expires] [Timer Expires]
ClientHello ------> ClientHello ------>
(retransmit) (retransmit)
Figure 1: DTLS retransmission example Figure 1: DTLS Retransmission Example
Once the client has transmitted the ClientHello message, it expects Once the client has transmitted the ClientHello message, it expects
to see a HelloRetryRequest or a ServerHello from the server. to see a HelloRetryRequest or a ServerHello from the server.
However, if the timer expires, the client knows that either the However, if the timer expires, the client knows that either the
ClientHello or the response from the server has been lost, which ClientHello or the response from the server has been lost, which
causes the the client to retransmit the ClientHello. When the server causes the client to retransmit the ClientHello. When the server
receives the retransmission, it knows to retransmit its receives the retransmission, it knows to retransmit its
HelloRetryRequest or ServerHello. HelloRetryRequest or ServerHello.
The server also maintains a retransmission timer for messages it The server also maintains a retransmission timer for messages it
sends (other than HelloRetryRequest) and retransmits when that timer sends (other than HelloRetryRequest) and retransmits when that timer
expires. Not applying retransmissions to the HelloRetryRequest expires. Not applying retransmissions to the HelloRetryRequest
avoids the need to create state on the server. 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, is designed to be small enough that it will not itself be fragmented,
thus avoiding concerns about interleaving multiple thus avoiding concerns about interleaving multiple
HelloRetryRequests. HelloRetryRequests.
skipping to change at page 8, line 33 skipping to change at line 339
a recipient in possession of all bytes of a handshake message can a recipient in possession of all bytes of a handshake message can
reassemble the original unfragmented message. reassemble the original unfragmented message.
3.4. Replay Detection 3.4. Replay Detection
DTLS optionally supports record replay detection. The technique used DTLS optionally supports record replay detection. The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of 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 received records. Records that are too old to fit in the window and
records that have previously been received are silently discarded. records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors. not always malicious but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy. modify their data transmission strategy.
4. The DTLS Record Layer 4. The DTLS Record Layer
The DTLS 1.3 record layer is different from the TLS 1.3 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. and also different from the DTLS 1.2 record layer.
1. The DTLSCiphertext structure omits the superfluous version number 1. The DTLSCiphertext structure omits the superfluous version number
and type fields. and type fields.
2. DTLS adds an epoch and sequence number to the TLS record header. 2. DTLS adds an epoch and sequence number to the TLS record header.
This sequence number allows the recipient to correctly verify the This sequence number allows the recipient to correctly decrypt
DTLS MAC. However, the number of bits used for the epoch and and verify DTLS records. However, the number of bits used for
sequence number fields in the DTLSCiphertext structure have been the epoch and sequence number fields in the DTLSCiphertext
reduced from those in previous versions. structure has been reduced from those in previous versions.
3. The DTLSCiphertext structure has a variable length header. 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 DTLSPlaintext records are used to send unprotected records and
DTLSCiphertext records are used to send protected records. DTLSCiphertext records are used to send protected records.
The DTLS record formats are shown below. Unless explicitly stated The DTLS record formats are shown below. Unless explicitly stated
the meaning of the fields is unchanged from previous TLS / DTLS the meaning of the fields is unchanged from previous TLS/DTLS
versions. versions.
struct { struct {
ContentType type; ContentType type;
ProtocolVersion legacy_record_version; ProtocolVersion legacy_record_version;
uint16 epoch = 0 uint16 epoch = 0
uint48 sequence_number; uint48 sequence_number;
uint16 length; uint16 length;
opaque fragment[DTLSPlaintext.length]; opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext; } DTLSPlaintext;
skipping to change at page 9, line 34 skipping to change at line 397
uint8 zeros[length_of_padding]; uint8 zeros[length_of_padding];
} DTLSInnerPlaintext; } DTLSInnerPlaintext;
struct { struct {
opaque unified_hdr[variable]; opaque unified_hdr[variable];
opaque encrypted_record[length]; opaque encrypted_record[length];
} DTLSCiphertext; } DTLSCiphertext;
Figure 2: DTLS 1.3 Record Formats Figure 2: DTLS 1.3 Record Formats
legacy_record_version This value MUST be set to {254, 253} for all legacy_record_version: This value MUST be set to {254, 253} for all
records other than the initial ClientHello (i.e., one not records other than the initial ClientHello (i.e., one not
generated after a HelloRetryRequest), where it may also be {254, generated after a HelloRetryRequest), where it may also be {254,
255} for compatibility purposes. It MUST be ignored for all 255} for compatibility purposes. It MUST be ignored for all
purposes. See [TLS13]; Appendix D.1 for the rationale for this. 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 unified_hdr: The unified header (unified_hdr) is a structure of
variable length, as shown in Figure 3. variable length, shown in Figure 3.
encrypted_record: The AEAD-encrypted form of the serialized encrypted_record: The encrypted form of the serialized
DTLSInnerPlaintext structure. DTLSInnerPlaintext structure.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|1|C|S|L|E E| |0|0|1|C|S|L|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Connection ID | Legend: | Connection ID | Legend:
| (if any, | | (if any, |
/ length as / C - Connection ID (CID) present / length as / C - Connection ID (CID) present
| negotiated) | S - Sequence number length | negotiated) | S - Sequence number length
skipping to change at page 10, line 29 skipping to change at line 435
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: DTLS 1.3 Unified Header Figure 3: DTLS 1.3 Unified Header
Fixed Bits: The three high bits of the first byte of the unified 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 header are set to 001. This ensures that the value will fit
within the DTLS region when multiplexing is performed as described within the DTLS region when multiplexing is performed as described
in [RFC7983]. It also ensures that distinguishing encrypted DTLS in [RFC7983]. It also ensures that distinguishing encrypted DTLS
1.3 records from encrypted DTLS 1.2 records is possible when they 1.3 records from encrypted DTLS 1.2 records is possible when they
are carried on the same host/port quartet; such multiplexing is are carried on the same host/port quartet; such multiplexing is
only possible when CIDs [I-D.ietf-tls-dtls-connection-id] are in only possible when CIDs [RFC9146] are in use, in which case DTLS
use, in which case DTLS 1.2 records will have the content type 1.2 records will have the content type tls12_cid (25).
tls12_cid (25).
C: The C bit (0x10) is set if the Connection ID is present. 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 S: The S bit (0x08) indicates the size of the sequence number. 0
means an 8-bit sequence number, 1 means 16-bit. Implementations means an 8-bit sequence number, 1 means 16-bit. Implementations
MAY mix sequence numbers of different lengths on the same MAY mix sequence numbers of different lengths on the same
connection. connection.
L: The L bit (0x04) is set if the length is present. 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 E: The two low bits (0x03) include the low-order two bits of the
epoch. epoch.
Connection ID: Variable length CID. The CID functionality is Connection ID: Variable-length CID. The CID functionality is
described in [I-D.ietf-tls-dtls-connection-id]. An example can be described in [RFC9146]. An example can be found in Section 9.1.
found in Section 9.1.
Sequence Number: The low order 8 or 16 bits of the record sequence 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 number. This value is 16 bits if the S bit is set to 1, and 8
bits if the S bit is 0. bits if the S bit is 0.
Length: Identical to the length field in a TLS 1.3 record. Length: Identical to the length field in a TLS 1.3 record.
As with previous versions of DTLS, multiple DTLSPlaintext and As with previous versions of DTLS, multiple DTLSPlaintext and
DTLSCiphertext records can be included in the same underlying DTLSCiphertext records can be included in the same underlying
transport datagram. transport datagram.
Figure 4 illustrates different record headers. 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 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| | Content Type | |0|0|1|1|1|1|E E| |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 16 bit | | | |8-bit Seq. No. | | 16 bit | | | |8 bit Seq. No. |
| Version | / Connection ID / +-+-+-+-+-+-+-+-+ | Version | / Connection ID / +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+ | | | |
| 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted | | 16 bit | +-+-+-+-+-+-+-+-+ | Encrypted |
| Epoch | | 16 bit | / Record / | Epoch | | 16 bit | / Record /
+-+-+-+-+-+-+-+-+ |Sequence Number| | | +-+-+-+-+-+-+-+-+ |Sequence Number| | |
| | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | 16 bit | | | | 16 bit |
| 48 bit | | Length | DTLSCiphertext | 48 bit | | Length | DTLSCiphertext
|Sequence Number| +-+-+-+-+-+-+-+-+ Structure |Sequence Number| +-+-+-+-+-+-+-+-+ Structure
| | | | (minimal) | | | | (minimal)
skipping to change at page 11, line 46 skipping to change at line 498
| | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
DTLSPlaintext DTLSPlaintext
Structure Structure
Figure 4: DTLS 1.3 Header Examples Figure 4: DTLS 1.3 Header Examples
The length field MAY be omitted by clearing the L bit, which means 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 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 level transport. In this case, it is not possible to have multiple
DTLSCiphertext format records without length fields in the same DTLSCiphertext format records without length fields in the same
datagram. Omitting the length field MUST only be used for the last datagram. Omitting the length field MUST only be used for the last
record in a datagram. Implementations MAY mix records with and record in a datagram. Implementations MAY mix records with and
without length fields on the same connection. without length fields on the same connection.
If a Connection ID is negotiated, then it MUST be contained in all If a Connection ID is negotiated, then it MUST be contained in all
datagrams. Sending implementations MUST NOT mix records from datagrams. Sending implementations MUST NOT mix records from
multiple DTLS associations in the same datagram. If the second or multiple DTLS associations in the same datagram. If the second or
later record has a connection ID which does not correspond to the later record has a connection ID which does not correspond to the
same association used for previous records, the rest of the datagram same association used for previous records, the rest of the datagram
MUST be discarded. MUST be discarded.
When expanded, the epoch and sequence number can be combined into an When expanded, the epoch and sequence number can be combined into an
unpacked RecordNumber structure, as shown below: unpacked RecordNumber structure, as shown below:
struct { struct {
uint16 epoch; uint64 epoch;
uint48 sequence_number; uint64 sequence_number;
} RecordNumber; } RecordNumber;
This 64-bit value is used in the ACK message as well as in the This 128-bit value is used in the ACK message as well as in the
"record_sequence_number" input to the AEAD function. "record_sequence_number" input to the Authenticated Encryption with
Associated Data (AEAD) function. The entire header value shown in
The entire header value shown in Figure 4 (but prior to record number Figure 4 (but prior to record number encryption; see Section 4.2.3)
encryption, see Section 4.2.3) is used as as the additional data is used as the additional data value for the AEAD function. For
value for the AEAD function. For instance, if the minimal variant is instance, if the minimal variant is used, the Associated Data (AD) is
used, the AAD is 2 octets long. Note that this design is different 2 octets long. Note that this design is different from the
from the additional data calculation for DTLS 1.2 and for DTLS 1.2 additional data calculation for DTLS 1.2 and for DTLS 1.2 with
with Connection ID. 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 4.1. Demultiplexing DTLS Records
DTLS 1.3 uses a variable length record format and hence the DTLS 1.3's header format is more complicated to demux than DTLS 1.2,
demultiplexing process is more complex since more header formats need which always carried the content type as the first byte. As
to be distinguished. Implementations can demultiplex DTLS 1.3 described in Figure 5, the first byte determines how an incoming DTLS
records by examining the first byte as follows: 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, * If the first byte is alert(21), handshake(22), or ack(proposed,
26), the record MUST be interpreted as a DTLSPlaintext record. 26), the record MUST be interpreted as a DTLSPlaintext record.
* If the first byte is any other value, then receivers MUST check to * 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 see if the leading bits of the first byte are 001. If so, the
implementation MUST process the record as DTLSCiphertext; the true implementation MUST process the record as DTLSCiphertext; the true
content type will be inside the protected portion. content type will be inside the protected portion.
* Otherwise, the record MUST be rejected as if it had failed * Otherwise, the record MUST be rejected as if it had failed
deprotection, as described in Section 4.5.2. deprotection, as described in Section 4.5.2.
Figure 5 shows this demultiplexing procedure graphically taking DTLS Figure 5 shows this demultiplexing procedure graphically, taking DTLS
1.3 and earlier versions of DTLS into account. 1.3 and earlier versions of DTLS into account.
+----------------+ +----------------+
| Outer Content | | Outer Content |
| Type (OCT) | | Type (OCT) |
| | | |
| OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3) | OCT == 20 -+--> ChangeCipherSpec (DTLS <1.3)
| OCT == 21 -+--> Alert (Plaintext) | OCT == 21 -+--> Alert (Plaintext)
| OCT == 22 -+--> Handshake (Plaintext) | OCT == 22 -+--> DTLSHandshake (Plaintext)
| OCT == 23 -+--> Application Data (DTLS <1.3) | OCT == 23 -+--> Application Data (DTLS <1.3)
| OCT == 24 -+--> Heartbeat (DTLS <1.3) | OCT == 24 -+--> Heartbeat (DTLS <1.3)
packet --> | OCT == 25 -+--> DTLSCipherText with CID (DTLS 1.2) packet --> | OCT == 25 -+--> DTLSCiphertext with CID (DTLS 1.2)
| OCT == 26 -+--> ACK (DTLS 1.3, Plaintext) | OCT == 26 -+--> ACK (DTLS 1.3, Plaintext)
| | | |
| | /+----------------+\ | | /+----------------+\
| 31 < OCT < 64 -+--> |DTLS Ciphertext | | 31 < OCT < 64 -+--> |DTLSCiphertext |
| | |(header bits | | | |(header bits |
| else | | start with 001)| | else | | start with 001)|
| | | /+-------+--------+\ | | | /+-------+--------+\
+-------+--------+ | +-------+--------+ |
| | | |
v Decryption | v Decryption |
+---------+ +------+ +---------+ +------+
| Reject | | | Reject | |
+---------+ v +---------+ v
+----------------+ +----------------+
| Decrypted | | Decrypted |
| Content Type | | Content Type |
| (DCT) | | (DCT) |
| | | |
| DCT == 21 -+--> Alert | DCT == 21 -+--> Alert
| DCT == 22 -+--> Handshake | DCT == 22 -+--> DTLSHandshake
| DCT == 23 -+--> Application Data | DCT == 23 -+--> Application Data
| DCT == 24 -+--> Heartbeat | DCT == 24 -+--> Heartbeat
| DCT == 26 -+--> ACK | DCT == 26 -+--> ACK
| | | else ------+--> Error
+----------------+ +----------------+
Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records Figure 5: Demultiplexing DTLS 1.2 and DTLS 1.3 Records
Note: The optimized DTLS header format shown in Figure 3, which does
not carry the Content Type in the Unified Header format, requires a
different demultilexing strategy compared to what was used in
previous DTLS versions where the Content Type was conveyed in every
record. 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.
4.2. Sequence Number and Epoch 4.2. Sequence Number and Epoch
DTLS uses an explicit or partly explicit sequence number, rather than DTLS uses an explicit or partly explicit sequence number, rather than
an implicit one, carried in the sequence_number field of the record. an implicit one, carried in the sequence_number field of the record.
Sequence numbers are maintained separately for each epoch, with each Sequence numbers are maintained separately for each epoch, with each
sequence_number initially being 0 for each epoch. sequence_number initially being 0 for each epoch.
The epoch number is initially zero and is incremented each time The epoch number is initially zero and is incremented each time
keying material changes and a sender aims to rekey. More details are keying material changes and a sender aims to rekey. More details are
provided in Section 6.1. provided in Section 6.1.
4.2.1. Processing Guidelines 4.2.1. Processing Guidelines
Because DTLS records could be reordered, a record from epoch M may be Because DTLS records could be reordered, a record from epoch M may be
received after epoch N (where N > M) has begun. Implementations received after epoch N (where N > M) has begun. Implementations
SHOULD discard records from earlier epochs, but MAY choose to retain SHOULD discard records from earlier epochs but MAY choose to retain
keying material from previous epochs for up to the default MSL keying material from previous epochs for up to the default MSL
specified for TCP [RFC0793] to allow for packet reordering. (Note specified for TCP [RFC0793] to allow for packet reordering. (Note
that the intention here is that implementers use the current guidance that the intention here is that implementers use the current guidance
from the IETF for MSL, as specified in [RFC0793] or successors, not 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 that they attempt to interrogate the MSL that the system TCP stack is
using.) using.)
Conversely, it is possible for records that are protected with the Conversely, it is possible for records that are protected with the
new epoch to be received prior to the completion of a handshake. For new epoch to be received prior to the completion of a handshake. For
instance, the server may send its Finished message and then start instance, the server may send its Finished message and then start
transmitting data. Implementations MAY either buffer or discard such transmitting data. Implementations MAY either buffer or discard such
records, though when DTLS is used over reliable transports (e.g., records, though when DTLS is used over reliable transports (e.g.,
SCTP [RFC4960]), they SHOULD be buffered and processed once the SCTP [RFC4960]), they SHOULD be buffered and processed once the
handshake completes. Note that TLS's restrictions on when records handshake completes. Note that TLS's restrictions on when records
may be sent still apply, and the receiver treats the records as if may be sent still apply, and the receiver treats the records as if
they were sent in the right order. they were sent in the right order.
Implementations MUST send retransmissions of lost messages using the Implementations MUST send retransmissions of lost messages using the
same epoch and keying material as the original transmission. same epoch and keying material as the original transmission.
Implementations MUST either abandon an association or re-key prior to Implementations MUST either abandon an association or rekey prior to
allowing the sequence number to wrap. allowing the sequence number to wrap.
Implementations MUST NOT allow the epoch to wrap, but instead MUST Implementations MUST NOT allow the epoch to wrap, but instead MUST
establish a new association, terminating the old association. establish a new association, terminating the old association.
4.2.2. Reconstructing the Sequence Number and Epoch 4.2.2. Reconstructing the Sequence Number and Epoch
When receiving protected DTLS records, the recipient does not have a When receiving protected DTLS records, the recipient does not have a
full epoch or sequence number value in the record and so there is full epoch or sequence number value in the record and so there is
some opportunity for ambiguity. Because the full epoch and sequence some opportunity for ambiguity. Because the full sequence number is
number are used to compute the per-record nonce, failure to used to compute the per-record nonce and the epoch determines the
reconstruct these values leads to failure to deprotect the record, keys, failure to reconstruct these values leads to failure to
and so implementations MAY use a mechanism of their choice to deprotect the record, and so implementations MAY use a mechanism of
determine the full values. This section provides an algorithm which their choice to determine the full values. This section provides an
is comparatively simple and which implementations are RECOMMENDED to algorithm which is comparatively simple and which implementations are
follow. RECOMMENDED to follow.
If the epoch bits match those of the current epoch, then If the epoch bits match those of the current epoch, then
implementations SHOULD reconstruct the sequence number by computing implementations SHOULD reconstruct the sequence number by computing
the full sequence number which is numerically closest to one plus the the full sequence number which is numerically closest to one plus the
sequence number of the highest successfully deprotected record in the sequence number of the highest successfully deprotected record in the
current epoch. current epoch.
During the handshake phase, the epoch bits unambiguously indicate the During the handshake phase, the epoch bits unambiguously indicate the
correct key to use. After the handshake is complete, if the epoch correct key to use. After the handshake is complete, if the epoch
bits do not match those from the current epoch implementations SHOULD bits do not match those from the current epoch, implementations
use the most recent past epoch which has matching bits, and then SHOULD use the most recent past epoch which has matching bits, and
reconstruct the sequence number for that epoch as described above. then reconstruct the sequence number for that epoch as described
above.
4.2.3. Record Number Encryption 4.2.3. Record Number Encryption
In DTLS 1.3, when records are encrypted, record sequence numbers are In DTLS 1.3, when records are encrypted, record sequence numbers are
also encrypted. The basic pattern is that the underlying encryption also encrypted. The basic pattern is that the underlying encryption
algorithm used with the AEAD algorithm is used to generate a mask algorithm used with the AEAD algorithm is used to generate a mask
which is then XORed with the sequence number. which is then XORed with the sequence number.
When the AEAD is based on AES, then the Mask is generated by When the AEAD is based on AES, then the mask is generated by
computing AES-ECB on the first 16 bytes of the ciphertext: computing AES-ECB on the first 16 bytes of the ciphertext:
Mask = AES-ECB(sn_key, Ciphertext[0..15]) Mask = AES-ECB(sn_key, Ciphertext[0..15])
When the AEAD is based on ChaCha20, then the mask is generated by 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 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 the next 12 bytes as the nonce, passing them to the ChaCha20 block
function (Section 2.3 of [CHACHA]): function (Section 2.3 of [CHACHA]):
Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15]) Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
The sn_key is computed as follows: The sn_key is computed as follows:
[sender]_sn_key = HKDF-Expand-Label(Secret, "sn" , "", key_length) [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)
[sender] denotes the sending side. The Secret value to be used is [sender] denotes the sending side. The per-epoch Secret value to be
described in Section 7.3 of [TLS13]. Note that a new key is used for used is described in Section 7.3 of [TLS13]. Note that a new key is
each epoch: because the epoch is sent in the clear, this does not used for each epoch: because the epoch is sent in the clear, this
result in ambiguity. does not result in ambiguity.
The encrypted sequence number is computed by XORing the leading bytes The encrypted sequence number is computed by XORing the leading bytes
of the Mask with the on-the-wire representation of the sequence of the mask with the on-the-wire representation of the sequence
number. Decryption is accomplished by the same process. number. Decryption is accomplished by the same process.
This procedure requires the ciphertext length be at least 16 bytes. This procedure requires the ciphertext length to be at least 16
Receivers MUST reject shorter records as if they had failed bytes. Receivers MUST reject shorter records as if they had failed
deprotection, as described in Section 4.5.2. Senders MUST pad short deprotection, as described in Section 4.5.2. Senders MUST pad short
plaintexts out (using the conventional record padding mechanism) in plaintexts out (using the conventional record padding mechanism) in
order to make a suitable-length ciphertext. Note most of the DTLS order to make a suitable-length ciphertext. Note that most of the
AEAD algorithms have a 16-byte authentication tag and need no DTLS AEAD algorithms have a 16 byte authentication tag and need no
padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256 padding. However, some algorithms, such as TLS_AES_128_CCM_8_SHA256,
have a shorter authentication tag and may require padding for short have a shorter authentication tag and may require padding for short
inputs. inputs.
Future cipher suites, which are not based on AES or ChaCha20, MUST Future cipher suites, which are not based on AES or ChaCha20, MUST
define their own record sequence number encryption in order to be define their own record sequence number encryption in order to be
used with DTLS. used with DTLS.
Note that sequence number encryption is only applied to the Note that sequence number encryption is only applied to the
DTLSCiphertext structure and not to the DTLSPlaintext structure, DTLSCiphertext structure and not to the DTLSPlaintext structure, even
which also contains a sequence number. though it also contains a sequence number.
4.3. Transport Layer Mapping 4.3. Transport Layer Mapping
DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS messages MAY be fragmented into multiple DTLS records. Each
DTLS record MUST fit within a single datagram. In order to avoid IP DTLS record MUST fit within a single datagram. In order to avoid IP
fragmentation, clients of the DTLS record layer SHOULD attempt to fragmentation, clients of the DTLS record layer SHOULD attempt to
size records so that they fit within any Path MTU (PMTU) estimates size records so that they fit within any Path MTU (PMTU) estimates
obtained from the record layer. For more information about PMTU obtained from the record layer. For more information about PMTU
issues see Section 4.4. issues, see Section 4.4.
Multiple DTLS records MAY be placed in a single datagram. Records Multiple DTLS records MAY be placed in a single datagram. Records
are encoded consecutively. The length field from DTLS records are encoded consecutively. The length field from DTLS records
containing that field can be used to determine the boundaries between containing that field can be used to determine the boundaries between
records. The final record in a datagram can omit the length field. 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 The first byte of the datagram payload MUST be the beginning of a
record. Records MUST NOT span datagrams. record. Records MUST NOT span datagrams.
DTLS records without CIDs do not contain any association identifiers DTLS records without CIDs do not contain any association identifiers,
and applications must arrange to multiplex between associations. and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate With UDP, the host/port number is used to look up the appropriate
security association for incoming records without CIDs. security association for incoming records without CIDs.
Some transports, such as DCCP [RFC4340], provide their own sequence Some transports, such as DCCP [RFC4340], provide their own sequence
numbers. When carried over those transports, both the DTLS and the numbers. When carried over those transports, both the DTLS and the
transport sequence numbers will be present. Although this introduces transport sequence numbers will be present. Although this introduces
a small amount of inefficiency, the transport layer and DTLS sequence a small amount of inefficiency, the transport layer and DTLS sequence
numbers serve different purposes; therefore, for conceptual numbers serve different purposes; therefore, for conceptual
simplicity, it is superior to use both sequence numbers. simplicity, it is superior to use both sequence numbers.
skipping to change at page 17, line 29 skipping to change at line 753
handshake retransmissions may be held rather than transmitted handshake retransmissions may be held rather than transmitted
immediately, potentially leading to timeouts and spurious immediately, potentially leading to timeouts and spurious
retransmission. When DTLS is used over such transports, care should retransmission. When DTLS is used over such transports, care should
be taken not to overrun the likely congestion window. [RFC5238] be taken not to overrun the likely congestion window. [RFC5238]
defines a mapping of DTLS to DCCP that takes these issues into defines a mapping of DTLS to DCCP that takes these issues into
account. account.
4.4. PMTU Issues 4.4. PMTU Issues
In general, DTLS's philosophy is to leave PMTU discovery to the In general, DTLS's philosophy is to leave PMTU discovery to the
application. However, DTLS cannot completely ignore PMTU for three application. However, DTLS cannot completely ignore the PMTU for
reasons: three reasons:
* The DTLS record framing expands the datagram size, thus lowering * The DTLS record framing expands the datagram size, thus lowering
the effective PMTU from the application's perspective. the effective PMTU from the application's perspective.
* In some implementations, the application may not directly talk to * In some implementations, the application may not directly talk to
the network, in which case the DTLS stack may absorb ICMP the network, in which case the DTLS stack may absorb ICMP
[RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] "Datagram Too Big" indications [RFC1191] or ICMPv6 "Packet Too
"Packet Too Big" indications. Big" indications [RFC4443].
* The DTLS handshake messages can exceed the PMTU. * The DTLS handshake messages can exceed the PMTU.
In order to deal with the first two issues, the DTLS record layer In order to deal with the first two issues, the DTLS record layer
SHOULD behave as described below. SHOULD behave as described below.
If PMTU estimates are available from the underlying transport If PMTU estimates are available from the underlying transport
protocol, they should be made available to upper layer protocols. In protocol, they should be made available to upper layer protocols. In
particular: particular:
skipping to change at page 18, line 15 skipping to change at line 786
* For DTLS over DCCP, the upper layer protocol SHOULD be allowed to * For DTLS over DCCP, the upper layer protocol SHOULD be allowed to
obtain the current estimate of the PMTU. obtain the current estimate of the PMTU.
* For DTLS over TCP or SCTP, which automatically fragment and * For DTLS over TCP or SCTP, which automatically fragment and
reassemble datagrams, there is no PMTU limitation. However, the reassemble datagrams, there is no PMTU limitation. However, the
upper layer protocol MUST NOT write any record that exceeds the upper layer protocol MUST NOT write any record that exceeds the
maximum record size of 2^14 bytes. maximum record size of 2^14 bytes.
The DTLS record layer SHOULD also allow the upper layer protocol to The DTLS record layer SHOULD also allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS discover the amount of record expansion expected by the DTLS
processing; alternately it MAY report PMTU estimates minus the processing; alternately, it MAY report PMTU estimates minus the
estimated expansion from the transport layer and DTLS record framing. estimated expansion from the transport layer and DTLS record framing.
Note that DTLS does not defend against spoofed ICMP messages; Note that DTLS does not defend against spoofed ICMP messages;
implementations SHOULD ignore any such messages that indicate PMTUs implementations SHOULD ignore any such messages that indicate PMTUs
below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively. below the IPv4 and IPv6 minimums of 576 and 1280 bytes, respectively.
If there is a transport protocol indication that the PMTU was 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 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 Section 14 of [RFC4340]), then the DTLS record layer MUST inform the
upper layer protocol of the error. upper layer protocol of the error.
The DTLS record layer SHOULD NOT interfere with upper layer protocols The DTLS record layer SHOULD NOT interfere with upper layer protocols
performing PMTU discovery, whether via [RFC1191] and [RFC4821] for performing PMTU discovery, whether via [RFC1191] and [RFC4821] for
IPv4 or via [RFC8201] for IPv6. In particular: IPv4 or via [RFC8201] for IPv6. In particular:
* Where allowed by the underlying transport protocol, the upper * Where allowed by the underlying transport protocol, the upper
layer protocol SHOULD be allowed to set the state of the DF bit layer protocol SHOULD be allowed to set the state of the Don't
(in IPv4) or prohibit local fragmentation (in IPv6). Fragment (DF) bit (in IPv4) or prohibit local fragmentation (in
IPv6).
* If the underlying transport protocol allows the application to * If the underlying transport protocol allows the application to
request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD request PMTU probing (e.g., DCCP), the DTLS record layer SHOULD
honor this request. honor this request.
The final issue is the DTLS handshake protocol. From the perspective The final issue is the DTLS handshake protocol. From the perspective
of the DTLS record layer, this is merely another upper layer of the DTLS record layer, this is merely another upper layer
protocol. However, DTLS handshakes occur infrequently and involve protocol. However, DTLS handshakes occur infrequently and involve
only a few round trips; therefore, the handshake protocol PMTU only a few round trips; therefore, the handshake protocol PMTU
handling places a premium on rapid completion over accurate PMTU handling places a premium on rapid completion over accurate PMTU
skipping to change at page 19, line 30 skipping to change at line 849
protection. Sequence number verification SHOULD be performed using protection. Sequence number verification SHOULD be performed using
the following sliding window procedure, borrowed from Section 3.4.3 the following sliding window procedure, borrowed from Section 3.4.3
of [RFC4303]. Because each epoch resets the sequence number space, a of [RFC4303]. Because each epoch resets the sequence number space, a
separate sliding window is needed for each epoch. separate sliding window is needed for each epoch.
The received record counter for an epoch MUST be initialized to zero The received record counter for an epoch MUST be initialized to zero
when that epoch is first used. For each received record, the when that epoch is first used. For each received record, the
receiver MUST verify that the record contains a sequence number that receiver MUST verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received does not duplicate the sequence number of any other record received
in that epoch during the lifetime of the association. This check in that epoch during the lifetime of the association. This check
SHOULD happen after deprotecting the record; otherwise the record SHOULD happen after deprotecting the record; otherwise, the record
discard might itself serve as a timing channel for the record number. discard might itself serve as a timing channel for the record number.
Note that computing the full record number from the partial is still Note that computing the full record number from the partial is still
a potential timing channel for the record number, though a less a potential timing channel for the record number, though a less
powerful one than whether the record was deprotected. powerful one than whether the record was deprotected.
Duplicates are rejected through the use of a sliding receive window. Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following (How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must text describes the functionality that the implementation must
exhibit.) The receiver SHOULD pick a window large enough to handle exhibit.) The receiver SHOULD pick a window large enough to handle
any plausible reordering, which depends on the data rate. (The any plausible reordering, which depends on the data rate. (The
skipping to change at page 20, line 5 skipping to change at line 872
The "right" edge of the window represents the highest validated The "right" edge of the window represents the highest validated
sequence number value received in the epoch. Records that contain sequence number value received in the epoch. Records that contain
sequence numbers lower than the "left" edge of the window are sequence numbers lower than the "left" edge of the window are
rejected. Records falling within the window are checked against a rejected. Records falling within the window are checked against a
list of received records within the window. An efficient means for list of received records within the window. An efficient means for
performing this check, based on the use of a bit mask, is described 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 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 the window and is new, or if the record is to the right of the
window, then the record is new. window, then the record is new.
The window MUST NOT be updated until the record has been deprotected The window MUST NOT be updated due to a received record until that
successfully. record has been deprotected successfully.
4.5.2. Handling Invalid Records 4.5.2. Handling Invalid Records
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.). In general, invalid records invalid formatting, length, MAC, etc.). In general, invalid records
SHOULD be silently discarded, thus preserving the association; SHOULD be silently discarded, thus preserving the association;
however, an error MAY be logged for diagnostic purposes. however, an error MAY be logged for diagnostic purposes.
Implementations which choose to generate an alert instead, MUST Implementations which choose to generate an alert instead MUST
generate fatal alerts to avoid attacks where the attacker repeatedly generate fatal alerts to avoid attacks where the attacker repeatedly
probes the implementation to see how it responds to various types of probes the implementation to see how it responds to various types of
error. Note that if DTLS is run over UDP, then any implementation error. Note that if DTLS is run over UDP, then any implementation
which does this will be extremely susceptible to denial-of-service which does this will be extremely susceptible to DoS attacks because
(DoS) attacks because UDP forgery is so easy. Thus, generating fatal UDP forgery is so easy. Thus, generating fatal alerts is NOT
alerts is NOT RECOMMENDED for such transports, both to increase the RECOMMENDED for such transports, both to increase the reliability of
reliability of DTLS service and to avoid the risk of spoofing attacks DTLS service and to avoid the risk of spoofing attacks sending
sending traffic to unrelated third parties. traffic to unrelated third parties.
If DTLS is being carried over a transport that is resistant to 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 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 because an attacker will have difficulty forging a datagram that will
not be rejected by the transport layer. not be rejected by the transport layer.
Note that because invalid records are rejected at a layer lower than Note that because invalid records are rejected at a layer lower than
the handshake state machine, they do not affect pending the handshake state machine, they do not affect pending
retransmission timers. retransmission timers.
4.5.3. AEAD Limits 4.5.3. AEAD Limits
Section 5.5 of TLS [TLS13] defines limits on the number of records Section 5.5 of [TLS13] defines limits on the number of records that
that can be protected using the same keys. These limits are specific can be protected using the same keys. These limits are specific to
to an AEAD algorithm, and apply equally to DTLS. Implementations an AEAD algorithm and apply equally to DTLS. Implementations SHOULD
SHOULD NOT protect more records than allowed by the limit specified NOT protect more records than allowed by the limit specified for the
for the negotiated AEAD. Implementations SHOULD initiate a key negotiated AEAD. Implementations SHOULD initiate a key update before
update before reaching this limit. reaching this limit.
[TLS13] does not specify a limit for AEAD_AES_128_CCM, but the [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 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 to obtain the same confidentiality protection as the limits specified
in TLS. in TLS.
The usage limits defined in TLS 1.3 exist for protection against The usage limits defined in TLS 1.3 exist for protection against
attacks on confidentiality and apply to successful applications of attacks on confidentiality and apply to successful applications of
AEAD protection. The integrity protections in authenticated AEAD protection. The integrity protections in authenticated
encryption also depend on limiting the number of attempts to forge encryption also depend on limiting the number of attempts to forge
packets. TLS achieves this by closing connections after any record packets. TLS achieves this by closing connections after any record
fails an authentication check. In comparison, DTLS ignores any fails an authentication check. In comparison, DTLS ignores any
packet that cannot be authenticated, allowing multiple forgery packet that cannot be authenticated, allowing multiple forgery
attempts. attempts.
Implementations MUST count the number of received packets that fail Implementations MUST count the number of received packets that fail
authentication with each key. If the number of packets that fail authentication with each key. If the number of packets that fail
authentication exceed a limit that is specific to the AEAD in use, an authentication exceeds a limit that is specific to the AEAD in use,
implementation SHOULD immediately close the connection. an implementation SHOULD immediately close the connection.
Implementations SHOULD initiate a key update with update_requested Implementations SHOULD initiate a key update with update_requested
before reaching this limit. Once a key update has been initiated, before reaching this limit. Once a key update has been initiated,
the previous keys can be dropped when the limit is reached rather the previous keys can be dropped when the limit is reached rather
than closing the connection. Applying a limit reduces the than closing the connection. Applying a limit reduces the
probability that an attacker is able to successfully forge a packet; probability that an attacker is able to successfully forge a packet;
see [AEBounds] and [ROBUST]. see [AEBounds] and [ROBUST].
For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, 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. the limit on the number of records that fail authentication is 2^36.
Note that the analysis in [AEBounds] supports a higher limit for the Note that the analysis in [AEBounds] supports a higher limit for
AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification 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 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. 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, 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 does not have a limit on the number of records that fail
authentication that both limits the probability of forgery by the authentication that both limits the probability of forgery by the
same amount and does not expose implementations to the risk of denial 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 of service; see Appendix B.3. Therefore, TLS_AES_128_CCM_8_SHA256
MUST NOT be used in DTLS without additional safeguards against MUST NOT be used in DTLS without additional safeguards against
forgery. Implementations MUST set usage limits for forgery. Implementations MUST set usage limits for
AEAD_AES_128_CCM_8 based on an understanding of any additional AEAD_AES_128_CCM_8 based on an understanding of any additional
forgery protections that are used. forgery protections that are used.
Any TLS cipher suite that is specified for use with DTLS MUST define Any TLS cipher suite that is specified for use with DTLS MUST define
limits on the use of the associated AEAD function that preserves limits on the use of the associated AEAD function that preserves
margins for both confidentiality and integrity. That is, limits MUST margins for both confidentiality and integrity. That is, limits MUST
be specified for the number of packets that can be authenticated and be specified for the number of packets that can be authenticated and
for the number of packets that can fail authentication before a key for the number of packets that can fail authentication before a key
update is required. Providing a reference to any analysis upon which update is required. Providing a reference to any analysis upon which
values are based - and any assumptions used in that analysis - allows values are based -- and any assumptions used in that analysis --
limits to be adapted to varying usage conditions. allows limits to be adapted to varying usage conditions.
5. The DTLS Handshake Protocol 5. The DTLS Handshake Protocol
DTLS 1.3 re-uses the TLS 1.3 handshake messages and flows, with the DTLS 1.3 reuses the TLS 1.3 handshake messages and flows, with the
following changes: following changes:
1. To handle message loss, reordering, and fragmentation 1. To handle message loss, reordering, and fragmentation,
modifications to the handshake header are necessary. modifications to the handshake header are necessary.
2. Retransmission timers are introduced to handle message loss. 2. Retransmission timers are introduced to handle message loss.
3. A new ACK content type has been added for reliable message 3. A new ACK content type has been added for reliable message
delivery of handshake messages. delivery of handshake messages.
Note that TLS 1.3 already supports a cookie extension, which is used In addition, DTLS reuses TLS 1.3's "cookie" extension to provide a
to prevent denial-of-service attacks. This DoS prevention mechanism return-routability check as part of connection establishment. This
is described in more detail below since UDP-based protocols are more is an important DoS prevention mechanism for UDP-based protocols,
vulnerable to amplification attacks than a connection-oriented unlike TCP-based protocols, for which TCP establishes return-
transport like TCP that performs return-routability checks as part of routability as part of the connection establishment.
the connection establishment.
DTLS implementations do not use the TLS 1.3 "compatibility mode" DTLS implementations do not use the TLS 1.3 "compatibility mode"
described in Section D.4 of [TLS13]. DTLS servers MUST NOT echo the 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 "legacy_session_id" value from the client and endpoints MUST NOT send
ChangeCipherSpec messages. ChangeCipherSpec messages.
With these exceptions, the DTLS message formats, flows, and logic are With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3. the same as those of TLS 1.3.
5.1. Denial-of-Service Countermeasures 5.1. Denial-of-Service Countermeasures
Datagram security protocols are extremely susceptible to a variety of Datagram security protocols are extremely susceptible to a variety of
DoS attacks. Two attacks are of particular concern: DoS attacks. Two attacks are of particular concern:
1. An attacker can consume excessive resources on the server by 1. An attacker can consume excessive resources on the server by
transmitting a series of handshake initiation requests, causing transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform expensive the server to allocate state and potentially to perform expensive
cryptographic operations. cryptographic operations.
2. An attacker can use the server as an amplifier by sending 2. An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source address that connection initiation messages with a forged source address that
belongs to a victim. The server then sends its response to the belongs to a victim. The server then sends its response to the
victim machine, thus flooding it. Depending on the selected victim machine, thus flooding it. Depending on the selected
parameters this response message can be quite large, as is the parameters, this response message can be quite large, as is the
case for a Certificate message. case for a Certificate message.
In order to counter both of these attacks, DTLS borrows the stateless In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When cookie technique used by Photuris [RFC2522] and IKE [RFC7296]. When
the client sends its ClientHello message to the server, the server the client sends its ClientHello message to the server, the server
MAY respond with a HelloRetryRequest message. The HelloRetryRequest MAY respond with a HelloRetryRequest message. The HelloRetryRequest
message, as well as the cookie extension, is defined in TLS 1.3. The message, as well as the "cookie" extension, is defined in TLS 1.3.
HelloRetryRequest message contains a stateless cookie (see [TLS13]; The HelloRetryRequest message contains a stateless cookie (see
Section 4.2.2). The client MUST send a new ClientHello with the [TLS13], Section 4.2.2). The client MUST send a new ClientHello with
cookie added as an extension. The server then verifies the cookie the cookie added as an extension. The server then verifies the
and proceeds with the handshake only if it is valid. This mechanism cookie and proceeds with the handshake only if it is valid. This
forces the attacker/client to be able to receive the cookie, which mechanism forces the attacker/client to be able to receive the
makes DoS attacks with spoofed IP addresses difficult. This cookie, which makes DoS attacks with spoofed IP addresses difficult.
mechanism does not provide any defense against DoS attacks mounted This mechanism does not provide any defense against DoS attacks
from valid IP addresses. mounted from valid IP addresses.
The DTLS 1.3 specification changes how cookies are exchanged compared The DTLS 1.3 specification changes how cookies are exchanged compared
to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message and to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest message and
conveys the cookie to the client via an extension. The client conveys the cookie to the client via an extension. The client
receiving the cookie uses the same extension to place the cookie receiving the cookie uses the same extension to place the cookie
subsequently into a ClientHello message. DTLS 1.2 on the other hand subsequently into a ClientHello message. DTLS 1.2, on the other
used a separate message, namely the HelloVerifyRequest, to pass a hand, used a separate message, namely the HelloVerifyRequest, to pass
cookie to the client and did not utilize the extension mechanism. a cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reasons, the cookie field in the For backwards compatibility reasons, the cookie field in the
ClientHello is present in DTLS 1.3 but is ignored by a DTLS 1.3 ClientHello is present in DTLS 1.3 but is ignored by a DTLS
compliant server implementation. 1.3-compliant server implementation.
The exchange is shown in Figure 6. Note that the figure focuses on The exchange is shown in Figure 6. Note that the figure focuses on
the cookie exchange; all other extensions are omitted. the cookie exchange; all other extensions are omitted.
Client Server Client Server
------ ------ ------ ------
ClientHello ------> ClientHello ------>
<----- HelloRetryRequest <----- HelloRetryRequest
+ cookie + cookie
ClientHello ------> ClientHello ------>
+ cookie + cookie
[Rest of handshake] [Rest of handshake]
Figure 6: DTLS exchange with HelloRetryRequest containing the Figure 6: DTLS Exchange with HelloRetryRequest Containing the
"cookie" extension "cookie" Extension
The cookie extension is defined in Section 4.2.2 of [TLS13]. When The "cookie" extension is defined in Section 4.2.2 of [TLS13]. When
sending the initial ClientHello, the client does not have a cookie sending the initial ClientHello, the client does not have a cookie
yet. In this case, the cookie extension is omitted and the yet. In this case, the "cookie" extension is omitted and the
legacy_cookie field in the ClientHello message MUST be set to a zero- legacy_cookie field in the ClientHello message MUST be set to a zero-
length vector (i.e., a zero-valued single byte length field). length vector (i.e., a zero-valued single byte length field).
When responding to a HelloRetryRequest, the client MUST create a new When responding to a HelloRetryRequest, the client MUST create a new
ClientHello message following the description in Section 4.1.2 of ClientHello message following the description in Section 4.1.2 of
[TLS13]. [TLS13].
If the HelloRetryRequest message is used, the initial ClientHello and If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the the HelloRetryRequest are included in the calculation of the
transcript hash. The computation of the message hash for the transcript hash. The computation of the message hash for the
HelloRetryRequest is done according to the description in HelloRetryRequest is done according to the description in
Section 4.4.1 of [TLS13]. Section 4.4.1 of [TLS13].
The handshake transcript is not reset with the second ClientHello and The handshake transcript is not reset with the second ClientHello,
a stateless server-cookie implementation requires the content or hash and a stateless server-cookie implementation requires the content or
of the initial ClientHello (and HelloRetryRequest) to be stored in hash of the initial ClientHello (and HelloRetryRequest) to be stored
the cookie. The initial ClientHello is included in the handshake in the cookie. The initial ClientHello is included in the handshake
transcript as a synthetic "message_hash" message, so only the hash transcript as a synthetic "message_hash" message, so only the hash
value is needed for the handshake to complete, though the complete value is needed for the handshake to complete, though the complete
HelloRetryRequest contents are needed. HelloRetryRequest contents are needed.
When the second ClientHello is received, the server can verify that When the second ClientHello is received, the server can verify that
the cookie is valid and that the client can receive packets at the 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 given IP address. If the client's apparent IP address is embedded in
the cookie, this prevents an attacker from generating an acceptable the cookie, this prevents an attacker from generating an acceptable
ClientHello apparently from another user. ClientHello apparently from another user.
skipping to change at page 24, line 42 skipping to change at line 1090
defend against this attack by changing the secret value frequently, defend against this attack by changing the secret value frequently,
thus invalidating those cookies. If the server wishes to allow thus invalidating those cookies. If the server wishes to allow
legitimate clients to handshake through the transition (e.g., a legitimate clients to handshake through the transition (e.g., a
client received a cookie with Secret 1 and then sent the second client received a cookie with Secret 1 and then sent the second
ClientHello after the server has changed to Secret 2), the server can ClientHello after the server has changed to Secret 2), the server can
have a limited window during which it accepts both secrets. have a limited window during which it accepts both secrets.
[RFC7296] suggests adding a key identifier to cookies to detect this [RFC7296] suggests adding a key identifier to cookies to detect this
case. An alternative approach is simply to try verifying with both case. An alternative approach is simply to try verifying with both
secrets. It is RECOMMENDED that servers implement a key rotation secrets. It is RECOMMENDED that servers implement a key rotation
scheme that allows the server to manage keys with overlapping scheme that allows the server to manage keys with overlapping
lifetime. lifetimes.
Alternatively, the server can store timestamps in the cookie and Alternatively, the server can store timestamps in the cookie and
reject cookies that were generated outside a certain interval of reject cookies that were generated outside a certain interval of
time. time.
DTLS servers SHOULD perform a cookie exchange whenever a new DTLS servers SHOULD perform a cookie exchange whenever a new
handshake is being performed. If the server is being operated in an handshake is being performed. If the server is being operated in an
environment where amplification is not a problem, the server MAY be environment where amplification is not a problem, e.g., where ICE
configured not to perform a cookie exchange. The default SHOULD be [RFC8445] has been used to establish bidirectional connectivity, the
that the exchange is performed, however. In addition, the server MAY server MAY be configured not to perform a cookie exchange. The
choose not to do a cookie exchange when a session is resumed or, more default SHOULD be that the exchange is performed, however. In
generically, when the DTLS handshake uses a PSK-based key exchange addition, the server MAY choose not to do a cookie exchange when a
and the IP address matches one associated with the PSK. Servers session is resumed or, more generically, when the DTLS handshake uses
which process 0-RTT requests and send 0.5-RTT responses without a a PSK-based key exchange and the IP address matches one associated
cookie exchange risk being used in an amplification attack if the with the PSK. Servers which process 0-RTT requests and send 0.5-RTT
size of outgoing messages greatly exceeds the size of those that are responses without a cookie exchange risk being used in an
received. A server SHOULD limit the amount of data it sends toward a amplification attack if the size of outgoing messages greatly exceeds
client address to three times the amount of data sent by the client the size of those that are received. A server SHOULD limit the
before it verifies that the client is able to receive data at that amount of data it sends toward a client address to three times the
address. A client address is valid after a cookie exchange or amount of data sent by the client before it verifies that the client
handshake completion. Clients MUST be prepared to do a cookie is able to receive data at that address. A client address is valid
exchange with every handshake. Note that cookies are only valid for after a cookie exchange or handshake completion. Clients MUST be
the existing handshake and cannot be stored for future handshakes. 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 If a server receives a ClientHello with an invalid cookie, it MUST
terminate the handshake with an "illegal_parameter" alert. This terminate the handshake with an "illegal_parameter" alert. This
allows the client to restart the connection from scratch without a allows the client to restart the connection from scratch without a
cookie. cookie.
As described in Section 4.1.4 of [TLS13], clients MUST abort the As described in Section 4.1.4 of [TLS13], clients MUST abort the
handshake with an "unexpected_message" alert in response to any handshake with an "unexpected_message" alert in response to any
second HelloRetryRequest which was sent in the same connection (i.e., second HelloRetryRequest which was sent in the same connection (i.e.,
where the ClientHello was itself in response to a HelloRetryRequest). where the ClientHello was itself in response to a HelloRetryRequest).
DTLS clients which do not want to receive a Connection ID SHOULD DTLS clients which do not want to receive a Connection ID SHOULD
still offer the "connection_id" extension unless there is an still offer the "connection_id" extension [RFC9146] unless there is
application profile to the contrary. This permits a server which an application profile to the contrary. This permits a server which
wants to receive a CID to negotiate one. wants to receive a CID to negotiate one.
5.2. DTLS Handshake Message Format 5.2. DTLS Handshake Message Format
In order to support message loss, reordering, and message DTLS uses the same Handshake messages as TLS 1.3. However, prior to
fragmentation, DTLS modifies the TLS 1.3 handshake header: transmission they are converted to DTLSHandshake messages, which
contain extra data needed to support message loss, reordering, and
message fragmentation.
enum { enum {
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
new_session_ticket(4), new_session_ticket(4),
end_of_early_data(5), end_of_early_data(5),
encrypted_extensions(8), encrypted_extensions(8),
request_connection_id(9), /* New */
new_connection_id(10), /* New */
certificate(11), certificate(11),
certificate_request(13), certificate_request(13),
certificate_verify(15), certificate_verify(15),
finished(20), finished(20),
key_update(24), key_update(24),
message_hash(254), message_hash(254),
(255) (255)
} HandshakeType; } HandshakeType;
struct { struct {
skipping to change at page 26, line 37 skipping to change at line 1173
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData; case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions; case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate: Certificate; case certificate: Certificate;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
case new_session_ticket: NewSessionTicket; case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate; case key_update: KeyUpdate;
case request_connection_id: RequestConnectionId;
case new_connection_id: NewConnectionId;
} body; } body;
} Handshake; } 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 The first message each side transmits in each association always has
message_seq = 0. Whenever a new message is generated, the message_seq = 0. Whenever a new message is generated, the
message_seq value is incremented by one. When a message is message_seq value is incremented by one. When a message is
retransmitted, the old message_seq value is re-used, i.e., not retransmitted, the old message_seq value is reused, i.e., not
incremented. From the perspective of the DTLS record layer, the incremented. From the perspective of the DTLS record layer, the
retransmission is a new record. This record will have a new retransmission is a new record. This record will have a new
DTLSPlaintext.sequence_number value. DTLSPlaintext.sequence_number value.
Note: In DTLS 1.2 the message_seq was reset to zero in case of a 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 rehandshake (i.e., renegotiation). On the surface, a rehandshake
DTLS 1.2 shares similarities with a post-handshake message exchange in DTLS 1.2 shares similarities with a post-handshake message
in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset to exchange in DTLS 1.3. However, in DTLS 1.3 the message_seq is not
allow distinguishing a retransmission from a previously sent post- reset, to allow distinguishing a retransmission from a previously
handshake message from a newly sent post-handshake message. sent post-handshake message from a newly sent post-handshake
message.
DTLS implementations maintain (at least notionally) a DTLS implementations maintain (at least notionally) a
next_receive_seq counter. This counter is initially set to zero. next_receive_seq counter. This counter is initially set to zero.
When a handshake message is received, if its message_seq value When a handshake message is received, if its message_seq value
matches next_receive_seq, next_receive_seq is incremented and the matches next_receive_seq, next_receive_seq is incremented and the
message is processed. If the sequence number is less than message is processed. If the sequence number is less than
next_receive_seq, the message MUST be discarded. If the sequence next_receive_seq, the message MUST be discarded. If the sequence
number is greater than next_receive_seq, the implementation SHOULD number is greater than next_receive_seq, the implementation SHOULD
queue the message but MAY discard it. (This is a simple space/ queue the message but MAY discard it. (This is a simple space/
bandwidth tradeoff). bandwidth trade-off).
In addition to the handshake messages that are deprecated by the TLS In addition to the handshake messages that are deprecated by the TLS
1.3 specification, DTLS 1.3 furthermore deprecates the 1.3 specification, DTLS 1.3 furthermore deprecates the
HelloVerifyRequest message originally defined in DTLS 1.0. DTLS HelloVerifyRequest message originally defined in DTLS 1.0. DTLS
1.3-compliant implements MUST NOT use the HelloVerifyRequest to 1.3-compliant implementations MUST NOT use the HelloVerifyRequest to
execute a return-routability check. A dual-stack DTLS 1.2/DTLS 1.3 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. client MUST, however, be prepared to interact with a DTLS 1.2 server.
5.3. ClientHello Message 5.3. ClientHello Message
The format of the ClientHello used by a DTLS 1.3 client differs from The format of the ClientHello used by a DTLS 1.3 client differs from
the TLS 1.3 ClientHello format as shown below. the TLS 1.3 ClientHello format, as shown below.
uint16 ProtocolVersion; uint16 ProtocolVersion;
opaque Random[32]; opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { struct {
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2 ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random; Random random;
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
skipping to change at page 28, line 15 skipping to change at line 1252
ClientHello with a version number higher than it supports. In ClientHello with a version number higher than it supports. In
DTLS 1.3, the client indicates its version preferences in the DTLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (see Section 4.2.1 of [TLS13]) and "supported_versions" extension (see Section 4.2.1 of [TLS13]) and
the legacy_version field MUST be set to {254, 253}, which was the the legacy_version field MUST be set to {254, 253}, which was the
version number for DTLS 1.2. The supported_versions entries for 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 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. versions). The value 0xfefc is used to indicate DTLS 1.3.
random: Same as for TLS 1.3, except that the downgrade sentinels 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 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. 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 legacy_session_id: Versions of TLS and DTLS before version 1.3
supported a "session resumption" feature which has been merged supported a "session resumption" feature, which has been merged
with pre-shared keys in version 1.3. A client which has a cached with pre-shared keys (PSK) in version 1.3. A client which has a
session ID set by a pre-DTLS 1.3 server SHOULD set this field to cached session ID set by a pre-DTLS 1.3 server SHOULD set this
that value. Otherwise, it MUST be set as a zero-length vector field to that value. Otherwise, it MUST be set as a zero-length
(i.e., a zero-valued single byte length field). vector (i.e., a zero-valued single byte length field).
legacy_cookie: A DTLS 1.3-only client MUST set the legacy_cookie 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 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 any other value in this field, the server MUST abort the handshake
with an "illegal_parameter" alert. with an "illegal_parameter" alert.
cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may cipher_suites: Same as for TLS 1.3; only suites with DTLS-OK=Y may
be used. be used.
legacy_compression_methods: Same as for TLS 1.3. legacy_compression_methods: Same as for TLS 1.3.
skipping to change at page 28, line 44 skipping to change at line 1281
extensions: Same as for TLS 1.3. extensions: Same as for TLS 1.3.
5.4. ServerHello Message 5.4. ServerHello Message
The DTLS 1.3 ServerHello message is the same as the TLS 1.3 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 ServerHello message, except that the legacy_version field is set to
0xfefd, indicating DTLS 1.2. 0xfefd, indicating DTLS 1.2.
5.5. Handshake Message Fragmentation and Reassembly 5.5. Handshake Message Fragmentation and Reassembly
As described in Section 4.3 one or more handshake messages may be As described in Section 4.3, one or more handshake messages may be
carried in a single datagram. However, handshake messages are carried in a single datagram. However, handshake messages are
potentially bigger than the size allowed by the underlying datagram potentially bigger than the size allowed by the underlying datagram
transport. DTLS provides a mechanism for fragmenting a handshake transport. DTLS provides a mechanism for fragmenting a handshake
message over a number of records, each of which can be transmitted in message over a number of records, each of which can be transmitted in
separate datagrams, thus avoiding IP fragmentation. separate datagrams, thus avoiding IP fragmentation.
When transmitting the handshake message, the sender divides the When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges. The ranges MUST message into a series of N contiguous data ranges. The ranges MUST
NOT overlap. The sender then creates N handshake messages, all with NOT overlap. The sender then creates N DTLSHandshake messages, all
the same message_seq value as the original handshake message. Each with the same message_seq value as the original DTLSHandshake
new message is labeled with the fragment_offset (the number of bytes message. Each new message is labeled with the fragment_offset (the
contained in previous fragments) and the fragment_length (the length number of bytes contained in previous fragments) and the
of this fragment). The length field in all messages is the same as fragment_length (the length of this fragment). The length field in
the length field of the original message. An unfragmented message is all messages is the same as the length field of the original message.
a degenerate case with fragment_offset=0 and fragment_length=length. An unfragmented message is a degenerate case with fragment_offset=0
Each handshake message fragment that is placed into a record MUST be and fragment_length=length. Each handshake message fragment that is
delivered in a single UDP datagram. placed into a record MUST be delivered in a single UDP datagram.
When a DTLS implementation receives a handshake message fragment When a DTLS implementation receives a handshake message fragment
corresponding to the next expected handshake message sequence number, corresponding to the next expected handshake message sequence number,
it MUST buffer it until it has the entire handshake message. DTLS it MUST process it, either by buffering it until it has the entire
implementations MUST be able to handle overlapping fragment ranges. handshake message or by processing any in-order portions of the
This allows senders to retransmit handshake messages with smaller message. The transcript consists of complete TLS Handshake messages
fragment sizes if the PMTU estimate changes. Senders MUST NOT change (reassembled as necessary). Note that this requires removing the
handshake message bytes upon retransmission. Receivers MAY check message_seq, fragment_offset, and fragment_length fields to create
that retransmitted bytes are identical and SHOULD abort the handshake the Handshake structure.
with an "illegal_parameter" alert if the value of a byte changes.
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 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 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 part of the same flight. Thus, there are two acceptable ways to pack
two DTLS handshake messages into the same datagram: in the same two DTLS handshake messages into the same datagram: in the same
record or in separate records. record or in separate records.
5.6. End Of Early Data 5.6. EndOfEarlyData Message
The DTLS 1.3 handshake has one important difference from the TLS 1.3 The DTLS 1.3 handshake has one important difference from the TLS 1.3
handshake: the EndOfEarlyData message is omitted both from the wire handshake: the EndOfEarlyData message is omitted both from the wire
and the handshake transcript: because DTLS records have epochs, and the handshake transcript. Because DTLS records have epochs,
EndOfEarlyData is not necessary to determine when the early data is EndOfEarlyData is not necessary to determine when the early data is
complete, and because DTLS is lossy, attackers can trivially mount complete, and because DTLS is lossy, attackers can trivially mount
the deletion attacks that EndOfEarlyData prevents in TLS. Servers the deletion attacks that EndOfEarlyData prevents in TLS. Servers
SHOULD NOT accept records from epoch 1 indefinitely once they are SHOULD NOT accept records from epoch 1 indefinitely once they are
able to process records from epoch 3. Though reordering of IP able to process records from epoch 3. Though reordering of IP
packets can result in records from epoch 1 arriving after records 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 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 the round trip time. Servers could discard epoch 1 keys after the
first epoch 3 data arrives, or retain keys for processing epoch 1 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 data for a short period. (See Section 6.1 for the definitions of
skipping to change at page 30, line 30 skipping to change at line 1365
| | | x | ServerHello, EncryptedExtensions, | | | | x | ServerHello, EncryptedExtensions, |
| | | | CertificateRequest, Certificate, | | | | | CertificateRequest, Certificate, |
| | | | CertificateVerify, Finished | | | | | CertificateVerify, Finished |
+------+--------+--------+-----------------------------------+ +------+--------+--------+-----------------------------------+
| 1 | x | | Certificate, CertificateVerify, | | 1 | x | | Certificate, CertificateVerify, |
| | | | Finished | | | | | Finished |
+------+--------+--------+-----------------------------------+ +------+--------+--------+-----------------------------------+
| 1 | | x | NewSessionTicket | | 1 | | x | NewSessionTicket |
+------+--------+--------+-----------------------------------+ +------+--------+--------+-----------------------------------+
Table 1: Flight Handshake Message Combinations. Table 1: Flight Handshake Message Combinations
Remarks: Remarks:
* Table 1 does not highlight any of the optional messages. * Table 1 does not highlight any of the optional messages.
* Regarding note (1): When a handshake flight is sent without any * Regarding note (1): When a handshake flight is sent without any
expected response, as it is the case with the client's final expected response, as is the case with the client's final flight
flight or with the NewSessionTicket message, the flight must be or with the NewSessionTicket message, the flight must be
acknowledged with an ACK message. acknowledged with an ACK message.
Below are several example message exchange illustrating the flight Below are several example message exchanges illustrating the flight
concept. The notational conventions from [TLS13] are used. concept. The notational conventions from [TLS13] are used.
Client Server Client Server
+--------+ +--------+
ClientHello | Flight | ClientHello | Flight |
--------> +--------+ --------> +--------+
+--------+ +--------+
<-------- HelloRetryRequest | Flight | <-------- HelloRetryRequest | Flight |
+ cookie +--------+ + cookie +--------+
+--------+ +--------+
ClientHello | Flight | ClientHello | Flight |
+ cookie --------> +--------+ + cookie --------> +--------+
ServerHello ServerHello
{EncryptedExtensions} +--------+ {EncryptedExtensions} +--------+
{CertificateRequest*} | Flight | {CertificateRequest*} | Flight |
{Certificate*} +--------+ {Certificate*} +--------+
{CertificateVerify*} {CertificateVerify*}
{Finished} {Finished}
<-------- [Application Data*] <-------- [Application Data*]
{Certificate*} +--------+ {Certificate*} +--------+
{CertificateVerify*} | Flight | {CertificateVerify*} | Flight |
{Finished} --------> +--------+ {Finished} --------> +--------+
[Application Data] [Application Data]
+--------+ +--------+
<-------- [ACK] | Flight | <-------- [ACK] | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 7: Message flights for a full DTLS Handshake (with cookie Figure 7: Message Flights for a Full DTLS Handshake (with Cookie
exchange) Exchange)
ClientHello +--------+ ClientHello +--------+
+ pre_shared_key | Flight | + pre_shared_key | Flight |
+ psk_key_exchange_modes +--------+ + psk_key_exchange_modes +--------+
+ key_share* --------> + key_share* -------->
ServerHello ServerHello
+ pre_shared_key +--------+ + pre_shared_key +--------+
+ key_share* | Flight | + key_share* | Flight |
{EncryptedExtensions} +--------+ {EncryptedExtensions} +--------+
skipping to change at page 32, line 26 skipping to change at line 1435
+--------+ +--------+
{Finished} --------> | Flight | {Finished} --------> | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
+--------+ +--------+
<-------- [ACK] | Flight | <-------- [ACK] | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 8: Message flights for resumption and PSK handshake Figure 8: Message Flights for Resumption and PSK Handshake
(without cookie exchange) (without Cookie Exchange)
Client Server Client Server
ClientHello ClientHello
+ early_data + early_data
+ psk_key_exchange_modes +--------+ + psk_key_exchange_modes +--------+
+ key_share* | Flight | + key_share* | Flight |
+ pre_shared_key +--------+ + pre_shared_key +--------+
(Application Data*) --------> (Application Data*) -------->
skipping to change at page 33, line 31 skipping to change at line 1464
+--------+ +--------+
{Finished} --------> | Flight | {Finished} --------> | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
+--------+ +--------+
<-------- [ACK] | Flight | <-------- [ACK] | Flight |
[Application Data*] +--------+ [Application Data*] +--------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 9: Message flights for the Zero-RTT handshake Figure 9: Message Flights for the Zero-RTT Handshake
Client Server Client Server
+--------+ +--------+
<-------- [NewSessionTicket] | Flight | <-------- [NewSessionTicket] | Flight |
+--------+ +--------+
+--------+ +--------+
[ACK] --------> | Flight | [ACK] --------> | Flight |
+--------+ +--------+
Figure 10: Message flights for the NewSessionTicket message Figure 10: Message Flights for the NewSessionTicket Message
KeyUpdate, NewConnectionId and RequestConnectionId follow a similar KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar
pattern to NewSessionTicket: a single message sent by one side pattern to NewSessionTicket: a single message sent by one side
followed by an ACK by the other. followed by an ACK by the other.
5.8. Timeout and Retransmission 5.8. Timeout and Retransmission
5.8.1. State Machine 5.8.1. State Machine
DTLS uses a simple timeout and retransmission scheme with the state DTLS uses a simple timeout and retransmission scheme with the state
machine shown in Figure 11. machine shown in Figure 11.
skipping to change at page 36, line 5 skipping to change at line 1537
| | | |
+-----------+ +-----------+
| /|\ | /|\
| | | |
| | | |
+---+ +---+
Server read retransmit Server read retransmit
Retransmit ACK Retransmit ACK
Figure 11: DTLS timeout and retransmission state machine Figure 11: DTLS Timeout and Retransmission State Machine
The state machine has four basic states: PREPARING, SENDING, WAITING, The state machine has four basic states: PREPARING, SENDING, WAITING,
and FINISHED. and FINISHED.
In the PREPARING state, the implementation does whatever computations In the PREPARING state, the implementation does whatever computations
are necessary to prepare the next flight of messages. It then are necessary to prepare the next flight of messages. It then
buffers them up for transmission (emptying the transmission buffer buffers them up for transmission (emptying the transmission buffer
first) and enters the SENDING state. first) and enters the SENDING state.
In the SENDING state, the implementation transmits the buffered In the SENDING state, the implementation transmits the buffered
flight of messages. If the implementation has received one or more flight of messages. If the implementation has received one or more
ACKs (see Section 7) from the peer, then it SHOULD omit any messages ACKs (see Section 7) from the peer, then it SHOULD omit any messages
or message fragments which have already been ACKed. Once the or message fragments which have already been acknowledged. Once the
messages have been sent, the implementation then sets a retransmit messages have been sent, the implementation then sets a retransmit
timer and enters the WAITING state. timer and enters the WAITING state.
There are four ways to exit the WAITING state: There are four ways to exit the WAITING state:
1. The retransmit timer expires: the implementation transitions to 1. The retransmit timer expires: the implementation transitions to
the SENDING state, where it retransmits the flight, adjusts and the SENDING state, where it retransmits the flight, adjusts and
re-arms the retransmit timer (see Section 5.8.2), and returns to re-arms the retransmit timer (see Section 5.8.2), and returns to
the WAITING state. the WAITING state.
2. The implementation reads an ACK from the peer: upon receiving an 2. The implementation reads an ACK from the peer: upon receiving an
ACK for a partial flight (as mentioned in Section 7.1), the ACK for a partial flight (as mentioned in Section 7.1), the
implementation transitions to the SENDING state, where it implementation transitions to the SENDING state, where it
retransmits the unacked portion of the flight, adjusts and re- retransmits the unacknowledged portion of the flight, adjusts and
arms the retransmit timer, and returns to the WAITING state. re-arms the retransmit timer, and returns to the WAITING state.
Upon receiving an ACK for a complete flight, the implementation Upon receiving an ACK for a complete flight, the implementation
cancels all retransmissions and either remains in WAITING, or, if cancels all retransmissions and either remains in WAITING, or, if
the ACK was for the final flight, transitions to FINISHED. the ACK was for the final flight, transitions to FINISHED.
3. The implementation reads a retransmitted flight from the peer: 3. The implementation reads a retransmitted flight from the peer
the implementation transitions to the SENDING state, where it when none of the messages that it sent in response to that flight
retransmits the flight, adjusts and re-arms the retransmit timer, have been acknowledged: the implementation transitions to the
and returns to the WAITING state. The rationale here is that the SENDING state, where it retransmits the flight, adjusts and re-
receipt of a duplicate message is the likely result of timer arms the retransmit timer, and returns to the WAITING state. The
expiry on the peer and therefore suggests that part of one's rationale here is that the receipt of a duplicate message is the
previous flight was lost. 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 4. The implementation receives some or all of the next flight of
messages: if this is the final flight of messages, the messages: if this is the final flight of messages, the
implementation transitions to FINISHED. If the implementation implementation transitions to FINISHED. If the implementation
needs to send a new flight, it transitions to the PREPARING needs to send a new flight, it transitions to the PREPARING
state. Partial reads (whether partial messages or only some of state. Partial reads (whether partial messages or only some of
the messages in the flight) may also trigger the implementation the messages in the flight) may also trigger the implementation
to send an ACK, as described in Section 7.1. to send an ACK, as described in Section 7.1.
Because DTLS clients send the first message (ClientHello), they start Because DTLS clients send the first message (ClientHello), they start
skipping to change at page 37, line 28 skipping to change at line 1610
until they have received the Finished message from the peer. until they have received the Finished message from the peer.
Implementations MAY treat receipt of application data with a new Implementations MAY treat receipt of application data with a new
epoch prior to receipt of the corresponding Finished message as epoch prior to receipt of the corresponding Finished message as
evidence of reordering or packet loss and retransmit their final evidence of reordering or packet loss and retransmit their final
flight immediately, shortcutting the retransmission timer. flight immediately, shortcutting the retransmission timer.
5.8.2. Timer Values 5.8.2. Timer Values
The configuration of timer settings varies with implementations, and The configuration of timer settings varies with implementations, and
certain deployment environments require timer value adjustments. certain deployment environments require timer value adjustments.
Mishandling of the timer can lead to serious congestion problems, for Mishandling of the timer can lead to serious congestion problems --
example if many instances of a DTLS time out early and retransmit too for example, if many instances of a DTLS time out early and
quickly on a congested link. retransmit too quickly on a congested link.
Unless implementations have deployment-specific and/or external Unless implementations have deployment-specific and/or external
information about the round trip time, implementations SHOULD use an information about the round trip time, implementations SHOULD use an
initial timer value of 1000 ms and double the value at each initial timer value of 1000 ms and double the value at each
retransmission, up to no less than 60 seconds (the RFC 6298 [RFC6298] retransmission, up to no less than 60 seconds (the maximum as
maximum). Application specific profiles MAY recommend shorter or specified in RFC 6298 [RFC6298]). Application-specific profiles MAY
longer timer values. For instance: recommend shorter or longer timer values. For instance:
* Profiles for specific deployment environments, such as in low- * Profiles for specific deployment environments, such as in low-
power, multi-hop mesh scenarios as used in some Internet of Things power, multi-hop mesh scenarios as used in some Internet of Things
(IoT) networks, MAY specify longer timeouts. See (IoT) networks, MAY specify longer timeouts. See [IOT-PROFILE]
[I-D.ietf-uta-tls13-iot-profile] for more information about one for more information about one such DTLS 1.3 IoT profile.
such DTLS 1.3 IoT profile.
* Real-time protocols MAY specify shorter timeouts. It is * Real-time protocols MAY specify shorter timeouts. It is
RECOMMENDED that for DTLS-SRTP [RFC5764], a default timeout of RECOMMENDED that for DTLS-SRTP [RFC5764], a default timeout of 400
400ms be used; because customer experience degrades with one-way ms be used; because customer experience degrades with one-way
latencies of greater than 200ms, real-time deployments are less latencies of greater than 200 ms, real-time deployments are less
likely to have long latencies. likely to have long latencies.
In settings where there is external information (for instance from an In settings where there is external information (for instance, from
ICE [RFC8445] handshake, or from previous connections to the same an ICE [RFC8445] handshake, or from previous connections to the same
server) about the RTT, implementations SHOULD use 1.5 times that RTT server) about the RTT, implementations SHOULD use 1.5 times that RTT
estimate as the retransmit timer. estimate as the retransmit timer.
Implementations SHOULD retain the current timer value until a message Implementations SHOULD retain the current timer value until a message
is transmitted and acknowledged without having to be retransmitted, is transmitted and acknowledged without having to be retransmitted,
at which time the value SHOULD be adjusted to 1.5 times the measured 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, round trip time for that message. After a long period of idleness,
no less than 10 times the current timer value, implementations MAY no less than 10 times the current timer value, implementations MAY
reset the timer to the initial value. reset the timer to the initial value.
Note that because retransmission is for the handshake and not Note that because retransmission is for the handshake and not
dataflow, the effect on congestion of shorter timeouts is smaller dataflow, the effect on congestion of shorter timeouts is smaller
than in generic protocols such as TCP or QUIC. Experience with DTLS than in generic protocols such as TCP or QUIC. Experience with DTLS
1.2, which uses a simpler "retransmit everything on timeout" 1.2, which uses a simpler "retransmit everything on timeout"
approach, has not shown serious congestion problems in practice. approach, has not shown serious congestion problems in practice.
5.8.3. Large Flight Sizes 5.8.3. Large Flight Sizes
DTLS does not have any built-in congestion control or rate control; 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. in general, this is not an issue because messages tend to be small.
However, in principle, some messages - especially Certificate - can However, in principle, some messages -- especially Certificate -- can
be quite large. If all the messages in a large flight are sent at 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 once, this can result in network congestion. A better strategy is to
send out only part of the flight, sending more when messages are send out only part of the flight, sending more when messages are
acknowledged. Several extensions have been standardized to reduce acknowledged. Several extensions have been standardized to reduce
the size of the certificate message, for example the cached the size of the Certificate message -- for example, the "cached_info"
information extension [RFC7924], certificate compression [RFC8879] extension [RFC7924]; certificate compression [RFC8879]; and
and [RFC6066], which defines the "client_certificate_url" extension [RFC6066], which defines the "client_certificate_url" extension
allowing DTLS clients to send a sequence of Uniform Resource Locators allowing DTLS clients to send a sequence of Uniform Resource Locators
(URLs) instead of the client certificate. (URLs) instead of the client certificate.
DTLS stacks SHOULD NOT send more than 10 records in a single DTLS stacks SHOULD NOT send more than 10 records in a single
transmission. transmission.
5.8.4. State machine duplication for post-handshake messages 5.8.4. State Machine Duplication for Post-Handshake Messages
DTLS 1.3 makes use of the following categories of post-handshake DTLS 1.3 makes use of the following categories of post-handshake
messages: messages:
1. NewSessionTicket 1. NewSessionTicket
2. KeyUpdate 2. KeyUpdate
3. NewConnectionId 3. NewConnectionId
skipping to change at page 39, line 4 skipping to change at line 1680
DTLS 1.3 makes use of the following categories of post-handshake DTLS 1.3 makes use of the following categories of post-handshake
messages: messages:
1. NewSessionTicket 1. NewSessionTicket
2. KeyUpdate 2. KeyUpdate
3. NewConnectionId 3. NewConnectionId
4. RequestConnectionId 4. RequestConnectionId
5. Post-handshake client authentication 5. Post-handshake client authentication
Messages of each category can be sent independently, and reliability Messages of each category can be sent independently, and reliability
is established via independent state machines each of which behaves is established via independent state machines, each of which behaves
as described in Section 5.8.1. For example, if a server sends a as described in Section 5.8.1. For example, if a server sends a
NewSessionTicket and a CertificateRequest message, two independent NewSessionTicket and a CertificateRequest message, two independent
state machines will be created. state machines will be created.
As explained in the corresponding sections, sending multiple Sending multiple instances of messages of a given category without
instances of messages of a given category without having completed having completed earlier transmissions is allowed for some
earlier transmissions is allowed for some categories, but not for categories, but not for others. Specifically, a server MAY send
others. Specifically, a server MAY send multiple NewSessionTicket multiple NewSessionTicket messages at once without awaiting ACKs for
messages at once without awaiting ACKs for earlier NewSessionTicket earlier NewSessionTicket messages first. Likewise, a server MAY send
first. Likewise, a server MAY send multiple CertificateRequest multiple CertificateRequest messages at once without having completed
messages at once without having completed earlier client earlier client authentication requests before. In contrast,
authentication requests before. In contrast, implementations MUST implementations MUST NOT send KeyUpdate, NewConnectionId, or
NOT send KeyUpdate, NewConnectionId or RequestConnectionId messages RequestConnectionId messages if an earlier message of the same type
if an earlier message of the same type has not yet been acknowledged. has not yet been acknowledged.
Note: Except for post-handshake client authentication, which involves Note: Except for post-handshake client authentication, which
handshake messages in both directions, post-handshake messages are involves handshake messages in both directions, post-handshake
single-flight, and their respective state machines on the sender side messages are single-flight, and their respective state machines on
reduce to waiting for an ACK and retransmitting the original message. the sender side reduce to waiting for an ACK and retransmitting
In particular, note that a RequestConnectionId message does not force the original message. In particular, note that a
the receiver to send a NewConnectionId message in reply, and both RequestConnectionId message does not force the receiver to send a
messages are therefore treated independently. NewConnectionId message in reply, and both messages are therefore
treated independently.
Creating and correctly updating multiple state machines requires Creating and correctly updating multiple state machines requires
feedback from the handshake logic to the state machine layer, feedback from the handshake logic to the state machine layer,
indicating which message belongs to which state machine. For indicating which message belongs to which state machine. For
example, if a server sends multiple CertificateRequest messages and example, if a server sends multiple CertificateRequest messages and
receives a Certificate message in response, the corresponding state receives a Certificate message in response, the corresponding state
machine can only be determined after inspecting the machine can only be determined after inspecting the
certificate_request_context field. Similarly, a server sending a certificate_request_context field. Similarly, a server sending a
single CertificateRequest and receiving a NewConnectionId message in single CertificateRequest and receiving a NewConnectionId message in
response can only decide that the NewConnectionId message should be response can only decide that the NewConnectionId message should be
treated through an independent state machine after inspecting the treated through an independent state machine after inspecting the
handshake message type. handshake message type.
5.9. CertificateVerify and Finished Messages 5.9. Cryptographic Label Prefix
CertificateVerify and Finished messages have the same format as in
TLS 1.3. Hash calculations include entire handshake messages,
including DTLS-specific fields: message_seq, fragment_offset, and
fragment_length. However, in order to remove sensitivity to
handshake message fragmentation, the CertificateVerify and the
Finished messages MUST be computed as if each handshake message had
been sent as a single fragment following the algorithm described in
Section 4.4.3 and Section 4.4.4 of [TLS13], respectively.
5.10. Cryptographic Label Prefix
Section 7.1 of [TLS13] specifies that HKDF-Expand-Label uses a label 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". 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 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 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 overall label size inside of one hash iteration because "DTLS" is one
letter longer than "TLS". letter longer than "TLS".
5.11. Alert Messages 5.10. Alert Messages
Note that Alert messages are not retransmitted at all, even when they Note that alert messages are not retransmitted at all, even when they
occur in the context of a handshake. However, a DTLS implementation occur in the context of a handshake. However, a DTLS implementation
which would ordinarily issue an alert SHOULD generate a new alert which would ordinarily issue an alert SHOULD generate a new alert
message if the offending record is received again (e.g., as a message if the offending record is received again (e.g., as a
retransmitted handshake message). Implementations SHOULD detect when retransmitted handshake message). Implementations SHOULD detect when
a peer is persistently sending bad messages and terminate the local a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected. Note that connection state after such misbehavior is detected. Note that
alerts are not reliably transmitted; implementation SHOULD NOT depend alerts are not reliably transmitted; implementations SHOULD NOT
on receiving alerts in order to signal errors or connection closure. depend on receiving alerts in order to signal errors or connection
closure.
5.12. Establishing New Associations with Existing Parameters 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 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 repeated connections happen on the same host/port quartet, then it is
possible that a client will silently abandon one connection and then possible that a client will silently abandon one connection and then
initiate another with the same parameters (e.g., after a reboot). 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 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 cases where a server believes it has an existing association on a
given host/port quartet and it receives an epoch=0 ClientHello, it given host/port quartet and it receives an epoch=0 ClientHello, it
SHOULD proceed with a new handshake but MUST NOT destroy the existing SHOULD proceed with a new handshake but MUST NOT destroy the existing
association until the client has demonstrated reachability either by association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message. After a correct including delivering a verifiable Finished message. After a correct
Finished message is received, the server MUST abandon the previous Finished message is received, the server MUST abandon the previous
association to avoid confusion between two valid associations with association to avoid confusion between two valid associations with
overlapping epochs. The reachability requirement prevents off-path/ overlapping epochs. The reachability requirement prevents off-path/
blind attackers from destroying associations merely by sending forged blind attackers from destroying associations merely by sending forged
ClientHellos. ClientHellos.
Note: it is not always possible to distinguish which association a Note: It is not always possible to distinguish which association a
given record is from. For instance, if the client performs a given record is from. For instance, if the client performs a
handshake, abandons the connection, and then immediately starts a new handshake, abandons the connection, and then immediately starts a
handshake, it may not be possible to tell which connection a given new handshake, it may not be possible to tell which connection a
protected record is for. In these cases, trial decryption may be given protected record is for. In these cases, trial decryption
necessary, though implementations could use CIDs to avoid the 5- may be necessary, though implementations could use CIDs to avoid
tuple-based ambiguity. the 5-tuple-based ambiguity.
6. Example of Handshake with Timeout and Retransmission 6. Example of Handshake with Timeout and Retransmission
The following is an example of a handshake with lost packets and The following is an example of a handshake with lost packets and
retransmissions. Note that the client sends an empty ACK message retransmissions. Note that the client sends an empty ACK message
because it can only acknowledge Record 2 sent by the server once it 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, has processed messages in Record 0 needed to establish epoch 2 keys,
which are needed to encrypt or decrypt messages found in Record 2. which are needed to encrypt or decrypt messages found in Record 2.
Section 7 provides the necessary background details for this Section 7 provides the necessary background details for this
interaction. Note: for simplicity we are not re-setting record interaction. Note: For simplicity, we are not resetting record
numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0, numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0",
etc.". etc.
Client Server Client Server
------ ------ ------ ------
Record 0 --------> Record 0 -------->
ClientHello ClientHello
(message_seq=0) (message_seq=0)
X<----- Record 0 X<----- Record 0
(lost) ServerHello (lost) ServerHello
skipping to change at page 42, line 29 skipping to change at line 1837
Certificate Certificate
(message_seq=1) (message_seq=1)
CertificateVerify CertificateVerify
(message_seq=2) (message_seq=2)
Finished Finished
(message_seq=3) (message_seq=3)
<-------- Record 5 <-------- Record 5
ACK [2] ACK [2]
Figure 12: Example DTLS exchange illustrating message loss Figure 12: Example DTLS Exchange Illustrating Message Loss
6.1. Epoch Values and Rekeying 6.1. Epoch Values and Rekeying
A recipient of a DTLS message needs to select the correct keying A recipient of a DTLS message needs to select the correct keying
material in order to process an incoming message. With the material in order to process an incoming message. With the
possibility of message loss and re-ordering, an identifier is needed possibility of message loss and reordering, an identifier is needed
to determine which cipher state has been used to protect the record to determine which cipher state has been used to protect the record
payload. The epoch value fulfills this role in DTLS. In addition to 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 the TLS 1.3-defined key derivation steps (see Section 7 of [TLS13]),
sender may want to rekey at any time during the lifetime of the 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 connection. It therefore needs to indicate that it is updating its
sending cryptographic keys. sending cryptographic keys.
This version of DTLS assigns dedicated epoch values to messages in This version of DTLS assigns dedicated epoch values to messages in
the protocol exchange to allow identification of the correct cipher the protocol exchange to allow identification of the correct cipher
state: state:
* epoch value (0) is used with unencrypted messages. There are * Epoch value (0) is used with unencrypted messages. There are
three unencrypted messages in DTLS, namely ClientHello, three unencrypted messages in DTLS, namely ClientHello,
ServerHello, and HelloRetryRequest. ServerHello, and HelloRetryRequest.
* epoch value (1) is used for messages protected using keys derived * Epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret. Note this epoch is skipped if from client_early_traffic_secret. Note that this epoch is skipped
the client does not offer early data. if the client does not offer early data.
* epoch value (2) is used for messages protected using keys derived * Epoch value (2) is used for messages protected using keys derived
from [sender]_handshake_traffic_secret. Messages transmitted from [sender]_handshake_traffic_secret. Messages transmitted
during the initial handshake, such as EncryptedExtensions, during the initial handshake, such as EncryptedExtensions,
CertificateRequest, Certificate, CertificateVerify, and Finished CertificateRequest, Certificate, CertificateVerify, and Finished,
belong to this category. Note, however, post-handshake are belong to this category. Note, however, that post-handshake
protected under the appropriate application traffic key and are messages are protected under the appropriate application traffic
not included in this category. key and are not included in this category.
* epoch value (3) is used for payloads protected using keys derived * Epoch value (3) is used for payloads protected using keys derived
from the initial [sender]_application_traffic_secret_0. This may from the initial [sender]_application_traffic_secret_0. This may
include handshake messages, such as post-handshake messages (e.g., include handshake messages, such as post-handshake messages (e.g.,
a NewSessionTicket message). a NewSessionTicket message).
* epoch value (4 to 2^16-1) is used for payloads protected using * Epoch values (4 to 2^64-1) are used for payloads protected using
keys from the [sender]_application_traffic_secret_N (N>0). keys from the [sender]_application_traffic_secret_N (N>0).
Using these reserved epoch values a receiver knows what cipher state Using these reserved epoch values, a receiver knows what cipher state
has been used to encrypt and integrity protect a message. has been used to encrypt and integrity protect a message.
Implementations that receive a record with an epoch value for which Implementations that receive a record with an epoch value for which
no corresponding cipher state can be determined SHOULD handle it as a no corresponding cipher state can be determined SHOULD handle it as a
record which fails deprotection. record which fails deprotection.
Note that epoch values do not wrap. If a DTLS implementation would Note that epoch values do not wrap. If a DTLS implementation would
need to wrap the epoch value, it MUST terminate the connection. need to wrap the epoch value, it MUST terminate the connection.
The traffic key calculation is described in Section 7.3 of [TLS13]. The traffic key calculation is described in Section 7.3 of [TLS13].
skipping to change at page 44, line 48 skipping to change at line 1951
Some time later ... Some time later ...
(Rekeying) (Rekeying)
Record 5 Record 5
<-------- [Application Data] <-------- [Application Data]
(epoch=4) (epoch=4)
Record 5 Record 5
[Application Data] --------> [Application Data] -------->
(epoch=4) (epoch=4)
Figure 13: Example DTLS exchange with epoch information Figure 13: Example DTLS Exchange with Epoch Information
7. ACK Message 7. ACK Message
The ACK message is used by an endpoint to indicate which handshake The ACK message is used by an endpoint to indicate which handshake
records it has received and processed from the other side. ACK is records it has received and processed from the other side. ACK is
not a handshake message but is rather a separate content type, with not a handshake message but is rather a separate content type, with
code point TBD (proposed, 25). This avoids having ACK being added to code point 26. This avoids having ACK being added to the handshake
the handshake transcript. Note that ACKs can still be sent in the transcript. Note that ACKs can still be sent in the same UDP
same UDP datagram as handshake records. datagram as handshake records.
struct { struct {
RecordNumber record_numbers<0..2^16-1>; RecordNumber record_numbers<0..2^16-1>;
} ACK; } ACK;
record_numbers: a list of the records containing handshake messages record_numbers: A list of the records containing handshake messages
in the current flight which the endpoint has received and either in the current flight which the endpoint has received and either
processed or buffered, in numerically increasing order. processed or buffered, in numerically increasing order.
Implementations MUST NOT acknowledge records containing handshake Implementations MUST NOT acknowledge records containing handshake
messages or fragments which have not been processed or buffered. messages or fragments which have not been processed or buffered.
Otherwise, deadlock can ensue. As an example, implementations MUST Otherwise, deadlock can ensue. As an example, implementations MUST
NOT send ACKs for handshake messages which they discard because they NOT send ACKs for handshake messages which they discard because they
are not the next expected message. are not the next expected message.
During the handshake, ACKs only cover the current outstanding flight During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lockstep protocol). In (this is possible because DTLS is generally a lock-step protocol).
particular, receiving a message from a handshake flight implicitly In particular, receiving a message from a handshake flight implicitly
acknowledges all messages from the previous flight(s). Accordingly, acknowledges all messages from the previous flight(s). Accordingly,
an ACK from the server would not cover both the ClientHello and the an ACK from the server would not cover both the ClientHello and the
client's Certificate, because the ClientHello and client Certificate client's Certificate message, because the ClientHello and client
are in different flights. Implementations can accomplish this by Certificate are in different flights. Implementations can accomplish
clearing their ACK list upon receiving the start of the next flight. this by clearing their ACK list upon receiving the start of the next
flight.
After the handshake, ACKs SHOULD be sent once for each received and For post-handshake messages, ACKs SHOULD be sent once for each
processed handshake record (potentially subject to some delay) and received and processed handshake record (potentially subject to some
MAY cover more than one flight. This includes records containing delay) and MAY cover more than one flight. This includes records
messages which are discarded because a previous copy has been containing messages which are discarded because a previous copy has
received. been received.
During the handshake, ACK records MUST be sent with an epoch that is 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 equal to or higher than the record which is being acknowledged. Note
that some care is required when processing flights spanning multiple that some care is required when processing flights spanning multiple
epochs. For instance, if the client receives only the Server Hello epochs. For instance, if the client receives only the ServerHello
and Certificate and wishes to ACK them in a single record, it must do 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 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. equal to 2 and cannot yet send with any greater epoch.
Implementations SHOULD simply use the highest current sending epoch, Implementations SHOULD simply use the highest current sending epoch,
which will generally be the highest available. After the handshake, which will generally be the highest available. After the handshake,
implementations MUST use the highest available sending epoch. implementations MUST use the highest available sending epoch.
7.1. Sending ACKs 7.1. Sending ACKs
When an implementation detects a disruption in the receipt of the When an implementation detects a disruption in the receipt of the
skipping to change at page 46, line 23 skipping to change at line 2021
* When they receive a message or fragment which is out of order, * When they receive a message or fragment which is out of order,
either because it is not the next expected message or because it either because it is not the next expected message or because it
is not the next piece of the current message. is not the next piece of the current message.
* When they have received part of a flight and do not immediately * 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 receive the rest of the flight (which may be in the same UDP
datagram). "Immediately" is hard to define. One approach is to datagram). "Immediately" is hard to define. One approach is to
set a timer for 1/4 the current retransmit timer value when the 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 first record in the flight is received and then send an ACK when
that timer expires. Note: the 1/4 value here is somewhat that timer expires. Note: The 1/4 value here is somewhat
arbitrary. Given that the round trip estimates in the DTLS arbitrary. Given that the round trip estimates in the DTLS
handshake are generally very rough (or the default), any value handshake are generally very rough (or the default), any value
will be an approximation, and there is an inherent compromise due will be an approximation, and there is an inherent compromise due
to competition between retransmision due to over-agressive ACKing to competition between retransmission due to over-aggressive
and over-aggressive timeout-based retransmission. As a comparison ACKing and over-aggressive timeout-based retransmission. As a
point, QUIC's loss-based recovery algorithms comparison point, QUIC's loss-based recovery algorithms
([I-D.ietf-quic-recovery]; Section 6.1.2) work out to a delay of ([RFC9002], Section 6.1.2) work out to a delay of about 1/3 of the
about 1/3 of the retransmit timer. retransmit timer.
In general, flights MUST be ACKed unless they are implicitly In general, flights MUST be ACKed unless they are implicitly
acknowledged. In the present specification the following flights are acknowledged. In the present specification, the following flights
implicitly acknowledged by the receipt of the next flight, which are implicitly acknowledged by the receipt of the next flight, which
generally immediately follows the flight, generally immediately follows the flight:
1. Handshake flights other than the client's final flight of the 1. Handshake flights other than the client's final flight of the
main handshake. main handshake.
2. The server's post-handshake CertificateRequest. 2. The server's post-handshake CertificateRequest.
ACKs SHOULD NOT be sent for these flights unless the responding ACKs SHOULD NOT be sent for these flights unless the responding
flight cannot be generated immediately. In this case, flight cannot be generated immediately. All other flights MUST be
implementations MAY send explicit ACKs for the complete received ACKed. In this case, implementations MAY send explicit ACKs for the
flight even though it will eventually also be implicitly acknowledged complete received flight even though it will eventually also be
through the responding flight. A notable example for this is the implicitly acknowledged through the responding flight. A notable
case of client authentication in constrained environments, where example for this is the case of client authentication in constrained
generating the CertificateVerify message can take considerable time environments, where generating the CertificateVerify message can take
on the client. All other flights MUST be ACKed. Implementations MAY considerable time on the client. Implementations MAY acknowledge the
acknowledge the records corresponding to each transmission of each records corresponding to each transmission of each flight or simply
flight or simply acknowledge the most recent one. In general, acknowledge the most recent one. In general, implementations SHOULD
implementations SHOULD ACK as many received packets as can fit into ACK as many received packets as can fit into the ACK record, as this
the ACK record, as this provides the most complete information and provides the most complete information and thus reduces the chance of
thus reduces the chance of spurious retransmission; if space is spurious retransmission; if space is limited, implementations SHOULD
limited, implementations SHOULD favor including records which have favor including records which have not yet been acknowledged.
not yet been acknowledged.
Note: While some post-handshake messages follow a request/response Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt. For example, a pattern, this does not necessarily imply receipt. For example, a
KeyUpdate sent in response to a KeyUpdate with request_update set to KeyUpdate sent in response to a KeyUpdate with request_update set
'update_requested' does not implicitly acknowledge the earlier to "update_requested" does not implicitly acknowledge the earlier
KeyUpdate message because the two KeyUpdate messages might have KeyUpdate message because the two KeyUpdate messages might have
crossed in flight. crossed in flight.
ACKs MUST NOT be sent for other records of any content type other ACKs MUST NOT be sent for records of any content type other than
than handshake or for records which cannot be unprotected. handshake or for records which cannot be deprotected.
Note that in some cases it may be necessary to send an ACK which does 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 not contain any record numbers. For instance, a client might receive
an EncryptedExtensions message prior to receiving a ServerHello. an EncryptedExtensions message prior to receiving a ServerHello.
Because it cannot decrypt the EncryptedExtensions, it cannot safely Because it cannot decrypt the EncryptedExtensions, it cannot safely
acknowledge it (as it might be damaged). If the client does not send acknowledge it (as it might be damaged). If the client does not send
an ACK, the server will eventually retransmit its first flight, but an ACK, the server will eventually retransmit its first flight, but
this might take far longer than the actual round trip time between this might take far longer than the actual round trip time between
client and server. Having the client send an empty ACK shortcuts client and server. Having the client send an empty ACK shortcuts
this process. this process.
7.2. Receiving ACKs 7.2. Receiving ACKs
When an implementation receives an ACK, it SHOULD record that the When an implementation receives an ACK, it SHOULD record that the
messages or message fragments sent in the records being ACKed were messages or message fragments sent in the records being ACKed were
received and omit them from any future retransmissions. Upon receipt received and omit them from any future retransmissions. Upon receipt
of an ACK that leaves it with only some messages from a flight having of an ACK that leaves it with only some messages from a flight having
been acknowledged an implementation SHOULD retransmit the been acknowledged, an implementation SHOULD retransmit the
unacknowledged messages or fragments. Note that this requires unacknowledged messages or fragments. Note that this requires
implementations to track which messages appear in which records. implementations to track which messages appear in which records.
Once all the messages in a flight have been acknowledged, the Once all the messages in a flight have been acknowledged, the
implementation MUST cancel all retransmissions of that flight. implementation MUST cancel all retransmissions of that flight.
Implementations MUST treat a record as having been acknowledged if it Implementations MUST treat a record as having been acknowledged if it
appears in any ACK; this prevents spurious retransmission in cases appears in any ACK; this prevents spurious retransmission in cases
where a flight is very large and the receiver is forced to elide where a flight is very large and the receiver is forced to elide
acknowledgements for records which have already been ACKed. As noted acknowledgements for records which have already been ACKed. As noted
above, the receipt of any record responding to a given flight MUST be above, the receipt of any record responding to a given flight MUST be
taken as an implicit acknowledgement for the entire flight to which taken as an implicit acknowledgement for the entire flight to which
it is responding. it is responding.
7.3. Design Rationale 7.3. Design Rationale
ACK messages are used in two circumstances, namely : ACK messages are used in two circumstances, namely:
* on sign of disruption, or lack of progress, and * On sign of disruption, or lack of progress; and
* to indicate complete receipt of the last flight in a handshake. * 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 In the first case, the use of the ACK message is optional, because
peer will retransmit in any case and therefore the ACK just allows the peer will retransmit in any case and therefore the ACK just
for selective or early retransmission, as opposed to the timeout- allows for selective or early retransmission, as opposed to the
based whole flight retransmission in previous versions of DTLS. When timeout-based whole flight retransmission in previous versions of
DTLS 1.3 is used in deployments with lossy networks, such as low- DTLS. When DTLS 1.3 is used in deployments with lossy networks, such
power, long range radio networks as well as low-power mesh networks, as low-power, long-range radio networks as well as low-power mesh
the use of ACKs is recommended. networks, the use of ACKs is recommended.
The use of the ACK for the second case is mandatory for the proper 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 functioning of the protocol. For instance, the ACK message sent by
the client in Figure 13, acknowledges receipt and processing of the client in Figure 13 acknowledges receipt and processing of Record
record 4 (containing the NewSessionTicket message) and if it is not 4 (containing the NewSessionTicket message), and if it is not sent,
sent the server will continue retransmission of the NewSessionTicket the server will continue retransmission of the NewSessionTicket
indefinitely until its maximum retransmission count is reached. indefinitely until its maximum retransmission count is reached.
8. Key Updates 8. Key Updates
As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to 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 indicate that they are updating their sending keys. As with other
handshake messages with no built-in response, KeyUpdates MUST be handshake messages with no built-in response, KeyUpdates MUST be
acknowledged. In order to facilitate epoch reconstruction acknowledged. In order to facilitate epoch reconstruction
Section 4.2.2 implementations MUST NOT send records with the new keys (Section 4.2.2), implementations MUST NOT send records with the new
or send a new KeyUpdate until the previous KeyUpdate has been keys or send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use). acknowledged (this avoids having too many epochs in active use).
Due to loss and/or re-ordering, DTLS 1.3 implementations may receive Due to loss and/or reordering, DTLS 1.3 implementations may receive a
a record with an older epoch than the current one (the requirements record with an older epoch than the current one (the requirements
above preclude receiving a newer record). They SHOULD attempt to above preclude receiving a newer record). They SHOULD attempt to
process those records with that epoch (see Section 4.2.2 for process those records with that epoch (see Section 4.2.2 for
information on determining the correct epoch), but MAY opt to discard information on determining the correct epoch) but MAY opt to discard
such out-of-epoch records. such out-of-epoch records.
Due to the possibility of an ACK message for a KeyUpdate being lost Due to the possibility of an ACK message for a KeyUpdate being lost
and thereby preventing the sender of the KeyUpdate from updating its and thereby preventing the sender of the KeyUpdate from updating its
keying material, receivers MUST retain the pre-update keying material keying material, receivers MUST retain the pre-update keying material
until receipt and successful decryption of a message using the new until receipt and successful decryption of a message using the new
keys. keys.
Figure 14 shows an example exchange illustrating that a successful Figure 14 shows an example exchange illustrating that successful ACK
ACK processing updates the keys of the KeyUpdate message sender, processing updates the keys of the KeyUpdate message sender, which is
which is reflected in the change of epoch values. reflected in the change of epoch values.
Client Server Client Server
/-------------------------------------------\ /-------------------------------------------\
| | | |
| Initial Handshake | | Initial Handshake |
\-------------------------------------------/ \-------------------------------------------/
[Application Data] --------> [Application Data] -------->
(epoch=3) (epoch=3)
skipping to change at page 49, line 37 skipping to change at line 2173
[Application Data] --------> [Application Data] -------->
(epoch=3) (epoch=3)
[KeyUpdate] [KeyUpdate]
(+ update_requested --------> (+ update_requested -------->
(epoch 3) (epoch 3)
<-------- [Application Data] <-------- [Application Data]
(epoch=3) (epoch=3)
[Ack] [ACK]
<-------- (epoch=3) <-------- (epoch=3)
[Application Data] [Application Data]
(epoch=4) --------> (epoch=4) -------->
<-------- [KeyUpdate] <-------- [KeyUpdate]
(epoch=3) (epoch=3)
[Ack] --------> [ACK] -------->
(epoch=4) (epoch=4)
<-------- [Application Data] <-------- [Application Data]
(epoch=4) (epoch=4)
Figure 14: Example DTLS Key Update 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 9. Connection ID Updates
If the client and server have negotiated the "connection_id" If the client and server have negotiated the "connection_id"
extension [I-D.ietf-tls-dtls-connection-id], either side can send a extension [RFC9146], either side can send a new CID that it wishes
new CID which it wishes the other side to use in a NewConnectionId the other side to use in a NewConnectionId message.
message.
enum { enum {
cid_immediate(0), cid_spare(1), (255) cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage; } ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>; opaque ConnectionId<0..2^8-1>;
struct { struct {
ConnectionIds cids<0..2^16-1>; ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage; ConnectionIdUsage usage;
} NewConnectionId; } NewConnectionId;
cid Indicates the set of CIDs which the sender wishes the peer to cids: Indicates the set of CIDs that the sender wishes the peer to
use. use.
usage Indicates whether the new CIDs should be used immediately or usage: Indicates whether the new CIDs should be used immediately or
are spare. If usage is set to "cid_immediate", then one of the are spare. If usage is set to "cid_immediate", then one of the
new CID MUST be used immediately for all future records. If it is new CIDs MUST be used immediately for all future records. If it
set to "cid_spare", then either existing or new CID MAY be used. 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 Endpoints SHOULD use receiver-provided CIDs in the order they were
provided. Implementations which receive more spare CIDs than they provided. Implementations which receive more spare CIDs than they
wish to maintain MAY simply discard any extra CIDs. Endpoints MUST wish to maintain MAY simply discard any extra CIDs. Endpoints MUST
NOT have more than one NewConnectionId message outstanding. NOT have more than one NewConnectionId message outstanding.
Implementations which either did not negotiate the "connection_id" Implementations which either did not negotiate the "connection_id"
extension or which have negotiated receiving an empty CID MUST NOT extension or which have negotiated receiving an empty CID MUST NOT
send NewConnectionId. Implementations MUST NOT send send NewConnectionId. Implementations MUST NOT send
RequestConnectionId when sending an empty Connection ID. RequestConnectionId when sending an empty Connection ID.
Implementations which detect a violation of these rules MUST Implementations which detect a violation of these rules MUST
terminate the connection with an "unexpected_message" alert. terminate the connection with an "unexpected_message" alert.
Implementations SHOULD use a new CID whenever sending on a new path, Implementations SHOULD use a new CID whenever sending on a new path
and SHOULD request new CIDs for this purpose if path changes are and SHOULD request new CIDs for this purpose if path changes are
anticipated. anticipated.
struct { struct {
uint8 num_cids; uint8 num_cids;
} RequestConnectionId; } RequestConnectionId;
num_cids The number of CIDs desired. num_cids: The number of CIDs desired.
Endpoints SHOULD respond to RequestConnectionId by sending a Endpoints SHOULD respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cid CIDs soon NewConnectionId with usage "cid_spare" containing num_cids CIDs as
as possible. Endpoints MUST NOT send a RequestConnectionId message soon as possible. Endpoints MUST NOT send a RequestConnectionId
when an existing request is still unfulfilled; this implies that message when an existing request is still unfulfilled; this implies
endpoints needs to request new CIDs well in advance. An endpoint MAY that endpoints need to request new CIDs well in advance. An endpoint
handle requests, which it considers excessive, by responding with a MAY handle requests which it considers excessive by responding with a
NewConnectionId message containing fewer than num_cid CIDs, including NewConnectionId message containing fewer than num_cids CIDs,
no CIDs at all. Endpoints MAY handle an excessive number of including no CIDs at all. Endpoints MAY handle an excessive number
RequestConnectionId messages by terminating the connection using a of RequestConnectionId messages by terminating the connection using a
"too_many_cids_requested" (alert number 52) alert. "too_many_cids_requested" (alert number 52) alert.
Endpoints MUST NOT send either of these messages if they did not Endpoints MUST NOT send either of these messages if they did not
negotiate a CID. If an implementation receives these messages when negotiate a CID. If an implementation receives these messages when
CIDs were not negotiated, it MUST abort the connection with an CIDs were not negotiated, it MUST abort the connection with an
unexpected_message alert. "unexpected_message" alert.
9.1. Connection ID Example 9.1. Connection ID Example
Below is an example exchange for DTLS 1.3 using a single CID in each Below is an example exchange for DTLS 1.3 using a single CID in each
direction. direction.
Note: The connection_id extension is defined in Note: The "connection_id" extension, which is used in ClientHello
[I-D.ietf-tls-dtls-connection-id], which is used in ClientHello and and ServerHello messages, is defined in [RFC9146].
ServerHello messages.
Client Server Client Server
------ ------ ------ ------
ClientHello ClientHello
(connection_id=5) (connection_id=5)
--------> -------->
<-------- HelloRetryRequest <-------- HelloRetryRequest
(cookie) (cookie)
ClientHello --------> ClientHello -------->
(connection_id=5) (connection_id=5)
+cookie + cookie
<-------- ServerHello <-------- ServerHello
(connection_id=100) (connection_id=100)
EncryptedExtensions EncryptedExtensions
(cid=5) (cid=5)
Certificate Certificate
(cid=5) (cid=5)
CertificateVerify CertificateVerify
(cid=5) (cid=5)
Finished Finished
(cid=5) (cid=5)
Certificate --------> Certificate -------->
(cid=100) (cid=100)
CertificateVerify CertificateVerify
(cid=100) (cid=100)
Finished Finished
(cid=100) (cid=100)
<-------- Ack <-------- ACK
(cid=5) (cid=5)
Application Data ========> Application Data ========>
(cid=100) (cid=100)
<======== Application Data <======== Application Data
(cid=5) (cid=5)
Figure 15: Example DTLS 1.3 Exchange with CIDs Figure 15: Example DTLS 1.3 Exchange with CIDs
If no CID is negotiated, then the receiver MUST reject any records it If no CID is negotiated, then the receiver MUST reject any records it
skipping to change at page 53, line 31 skipping to change at line 2345
that do not use the cookie exchange may be used as attack amplifiers that do not use the cookie exchange may be used as attack amplifiers
even if they themselves are not experiencing DoS. Therefore, DTLS even if they themselves are not experiencing DoS. Therefore, DTLS
servers SHOULD use the cookie exchange unless there is good reason to servers SHOULD use the cookie exchange unless there is good reason to
believe that amplification is not a threat in their environment. believe that amplification is not a threat in their environment.
Clients MUST be prepared to do a cookie exchange with every Clients MUST be prepared to do a cookie exchange with every
handshake. handshake.
Some key properties required of the cookie for the cookie-exchange Some key properties required of the cookie for the cookie-exchange
mechanism to be functional are described in Section 3.3 of [RFC2522]: mechanism to be functional are described in Section 3.3 of [RFC2522]:
* the cookie MUST depend on the client's address. * The cookie MUST depend on the client's address.
* it MUST NOT be possible for anyone other than the issuing entity * It MUST NOT be possible for anyone other than the issuing entity
to generate cookies that are accepted as valid by that entity. to generate cookies that are accepted as valid by that entity.
This typically entails an integrity check based on a secret key. This typically entails an integrity check based on a secret key.
* cookie generation and verification are triggered by * Cookie generation and verification are triggered by
unauthenticated parties, and as such their resource consumption unauthenticated parties, and as such their resource consumption
needs to be restrained in order to avoid having the cookie- needs to be restrained in order to avoid having the cookie-
exchange mechanism itself serve as a DoS vector. exchange mechanism itself serve as a DoS vector.
Although the cookie must allow the server to produce the right Although the cookie must allow the server to produce the right
handshake transcript, it SHOULD be constructed so that knowledge of handshake transcript, it SHOULD be constructed so that knowledge of
the cookie is insufficient to reproduce the ClientHello contents. the cookie is insufficient to reproduce the ClientHello contents.
Otherwise, this may create problems with future extensions such as Otherwise, this may create problems with future extensions such as
[I-D.ietf-tls-esni]. Encrypted Client Hello [TLS-ECH].
When cookies are generated using a keyed authentication mechanism it When cookies are generated using a keyed authentication mechanism, it
should be possible to rotate the associated secret key, so that should be possible to rotate the associated secret key, so that
temporary compromise of the key does not permanently compromise the temporary compromise of the key does not permanently compromise the
integrity of the cookie-exchange mechanism. Though this secret is integrity of the cookie-exchange mechanism. Though this secret is
not as high-value as, e.g., a session-ticket-encryption key, rotating 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 cookie-generation key on a similar timescale would ensure that
the key-rotation functionality is exercised regularly and thus in the key rotation functionality is exercised regularly and thus in
working order. working order.
The cookie exchange provides address validation during the initial The cookie exchange provides address validation during the initial
handshake. DTLS with Connection IDs allows for endpoint addresses to handshake. DTLS with Connection IDs allows for endpoint addresses to
change during the association; any such updated addresses are not change during the association; any such updated addresses are not
covered by the cookie exchange during the handshake. DTLS covered by the cookie exchange during the handshake. DTLS
implementations MUST NOT update the address they send to in response implementations MUST NOT update the address they send to in response
to packets from a different address unless they first perform some to packets from a different address unless they first perform some
reachability test; no such test is defined in this specification. reachability test; no such test is defined in this specification and
Even with such a test, an active on-path adversary can also black- a future specification would need to specify a complete procedure for
hole traffic or create a reflection attack against third parties how and when to update addresses. Even with such a test, an active
because a DTLS peer has no means to distinguish a genuine address on-path adversary can also black-hole traffic or create a reflection
update event (for example, due to a NAT rebinding) from one that is attack against third parties because a DTLS peer has no means to
malicious. This attack is of concern when there is a large asymmetry distinguish a genuine address update event (for example, due to a NAT
of request/response message sizes. 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 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 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 always provides order protection and non-replayability, DTLS does not
provide order protection and may not provide replay protection. provide order protection and may not provide replay protection.
Unlike TLS implementations, DTLS implementations SHOULD NOT respond Unlike TLS implementations, DTLS implementations SHOULD NOT respond
to invalid records by terminating the connection. to invalid records by terminating the connection.
TLS 1.3 requires replay protection for 0-RTT data (or rather, for 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 connections that use 0-RTT data; see Section 8 of [TLS13]). DTLS
provides an optional per-record replay-protection mechanism, since provides an optional per-record replay-protection mechanism, since
datagram protocols are inherently subject to message reordering and datagram protocols are inherently subject to message reordering and
replay. These two replay-protection mechanisms are orthogonal, and replay. These two replay-protection mechanisms are orthogonal, and
neither mechanism meets the requirements for the other. neither mechanism meets the requirements for the other.
The security and privacy properties of the CID for DTLS 1.3 builds on DTLS 1.3's handshake transcript does not include the new DTLS fields,
top of what is described for DTLS 1.2 in which makes it have the same format as TLS 1.3. However, the DTLS
[I-D.ietf-tls-dtls-connection-id]. There are, however, several 1.3 and TLS 1.3 transcripts are disjoint because they use different
differences: version numbers. Additionally, the DTLS 1.3 key schedule uses a
different label and so will produce different keys for the same
transcript.
* In both versions of DTLS extension negotiation is used to agree on The security and privacy properties of the CID for DTLS 1.3 build on
the use of the CID feature and the CID values. In both versions top of what is described for DTLS 1.2 in [RFC9146]. There are,
the CID is carried in the DTLS record header (if negotiated). however, several differences:
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 * In both versions of DTLS, extension negotiation is used to agree
server to update their CIDs and those values are exchanged with 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. confidentiality protection.
* The ability to use multiple CIDs allows for improved privacy * The ability to use multiple CIDs allows for improved privacy
properties in multi-homed scenarios. When only a single CID is in properties in multihomed scenarios. When only a single CID is in
use on multiple paths from such a host, an adversary can correlate use on multiple paths from such a host, an adversary can correlate
the communication interaction across paths, which adds further the communication interaction across paths, which adds further
privacy concerns. In order to prevent this, implementations privacy concerns. In order to prevent this, implementations
SHOULD attempt to use fresh CIDs whenever they change local SHOULD attempt to use fresh CIDs whenever they change local
addresses or ports (though this is not always possible to detect). addresses or ports (though this is not always possible to detect).
The RequestConnectionId message can be used by a peer to ask for The RequestConnectionId message can be used by a peer to ask for
new CIDs to ensure that a pool of suitable CIDs is available. new CIDs to ensure that a pool of suitable CIDs is available.
* The mechanism for encrypting sequence numbers (Section 4.2.3) * The mechanism for encrypting sequence numbers (Section 4.2.3)
prevents trivial tracking by on-path adversaries that attempt to prevents trivial tracking by on-path adversaries that attempt to
skipping to change at page 55, line 37 skipping to change at line 2454
* DTLS 1.3 encrypts handshake messages much earlier than in previous * DTLS 1.3 encrypts handshake messages much earlier than in previous
DTLS versions. Therefore, less information identifying the DTLS DTLS versions. Therefore, less information identifying the DTLS
client, such as the client certificate, is available to an on-path client, such as the client certificate, is available to an on-path
adversary. adversary.
12. Changes since DTLS 1.2 12. Changes since DTLS 1.2
Since TLS 1.3 introduces a large number of changes with respect to 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 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 large. For this reason, this section focuses on the most important
changes only. changes only.
* New handshake pattern, which leads to a shorter message exchange * New handshake pattern, which leads to a shorter message exchange.
* Only AEAD ciphers are supported. Additional data calculation has * Only AEAD ciphers are supported. Additional data calculation has
been simplified. been simplified.
* Removed support for weaker and older cryptographic algorithms * Removed support for weaker and older cryptographic algorithms.
* HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest * HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.
* More flexible ciphersuite negotiation * More flexible cipher suite negotiation.
* New session resumption mechanism * New session resumption mechanism.
* PSK authentication redefined
* PSK authentication redefined.
* New key derivation hierarchy utilizing a new key derivation * New key derivation hierarchy utilizing a new key derivation
construct construct.
* Improved version negotiation * Improved version negotiation.
* Optimized record layer encoding and thereby its size * Optimized record layer encoding and thereby its size.
* Added CID functionality * Added CID functionality.
* Sequence numbers are encrypted. * Sequence numbers are encrypted.
13. Updates affecting DTLS 1.2 13. Updates Affecting DTLS 1.2
This document defines several changes that optionally affect This document defines several changes that optionally affect
implementations of DTLS 1.2, including those which do not also implementations of DTLS 1.2, including those which do not also
support DTLS 1.3. support DTLS 1.3.
* A version downgrade protection mechanism as described in [TLS13]; * A version downgrade protection mechanism as described in [TLS13],
Section 4.1.3 and applying to DTLS as described in Section 5.3. Section 4.1.3 and applying to DTLS as described in Section 5.3.
* The updates described in [TLS13]; Section 3. * The updates described in [TLS13], Section 1.3.
* The new compliance requirements described in [TLS13]; Section 9.3. * The new compliance requirements described in [TLS13], Section 9.3.
14. IANA Considerations 14. IANA Considerations
IANA is requested to allocate a new value in the "TLS ContentType" IANA has allocated the content type value 26 in the "TLS ContentType"
registry for the ACK message, defined in Section 7, with content type registry for the ACK message, defined in Section 7. The value for
26. The value for the "DTLS-OK" column is "Y". IANA is requested to the "DTLS-OK" column is "Y". IANA has reserved the content type
reserve the content type range 32-63 so that content types in this range 32-63 so that content types in this range are not allocated.
range are not allocated.
IANA is requested to allocate "the too_many_cids_requested" alert in IANA has allocated value 52 for the "too_many_cids_requested" alert
the "TLS Alerts" registry with value 52. in the "TLS Alerts" registry. The value for the "DTLS-OK" column is
"Y".
IANA is requested to allocate two values in the "TLS Handshake Type" IANA has allocated two values in the "TLS HandshakeType" registry,
registry, defined in [TLS13], for RequestConnectionId (TBD), and defined in [TLS13], for request_connection_id (9) and
NewConnectionId (TBD), as defined in this document. The value for new_connection_id (10), as defined in this document. The value for
the "DTLS-OK" columns are "Y". the "DTLS-OK" column is "Y".
IANA is requested to add this RFC as a reference to the TLS Cipher IANA has added this RFC as a reference to the "TLS Cipher Suites"
Suite Registry along with the following Note: registry along with the following Note:
Any TLS cipher suite that is specified for use with DTLS MUST | Any TLS cipher suite that is specified for use with DTLS MUST
define limits on the use of the associated AEAD function that | define limits on the use of the associated AEAD function that
preserves margins for both confidentiality and integrity, | preserves margins for both confidentiality and integrity, as
as specified in [THIS RFC; Section TODO] | specified in Section 4.5.3 of RFC 9147.
15. References 15. References
15.1. Normative References 15.1. Normative References
[CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF [CHACHA] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>. <https://www.rfc-editor.org/info/rfc8439>.
[I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus,
"Connection Identifiers for DTLS 1.2", Work in Progress,
Internet-Draft, draft-ietf-tls-dtls-connection-id-11, 14
April 2021, <https://www.ietf.org/internet-drafts/draft-
ietf-tls-dtls-connection-id-11.txt>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
skipping to change at page 58, line 14 skipping to change at line 2564
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
15.2. Informative References 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-03, 12 July 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
aead-limits-03>.
[AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated [AEBounds] Luykx, A. and K. Paterson, "Limits on Authenticated
Encryption Use in TLS", 8 March 2016, Encryption Use in TLS", 28 August 2017,
<http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>. <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[CCM-ANALYSIS] [CCM-ANALYSIS]
Jonsson, J., "On the Security of CTR + CBC-MAC", Selected Jonsson, J., "On the Security of CTR + CBC-MAC", Selected
Areas in Cryptography pp. 76-93, Areas in Cryptography pp. 76-93,
DOI 10.1007/3-540-36492-7_7, 2003, DOI 10.1007/3-540-36492-7_7, February 2003,
<https://doi.org/10.1007/3-540-36492-7_7>. <https://doi.org/10.1007/3-540-36492-7_7>.
[DEPRECATE] [DEPRECATE]
Moriarty, K. and S. Farrell, "Deprecating TLSv1.0 and Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
TLSv1.1", Work in Progress, Internet-Draft, draft-ietf- 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
tls-oldversions-deprecate-12, 21 January 2021, <https://www.rfc-editor.org/info/rfc8996>.
<http://www.ietf.org/internet-drafts/draft-ietf-tls-
oldversions-deprecate-12.txt>.
[I-D.ietf-quic-recovery]
Iyengar, J. and I. Swett, "QUIC Loss Detection and
Congestion Control", Work in Progress, Internet-Draft,
draft-ietf-quic-recovery-34, 14 January 2021,
<https://www.ietf.org/internet-drafts/draft-ietf-quic-
recovery-34.txt>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-10, 8 March 2021,
<https://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
10.txt>.
[I-D.ietf-uta-tls13-iot-profile] [IOT-PROFILE]
Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for
the Internet of Things", Work in Progress, Internet-Draft, the Internet of Things", Work in Progress, Internet-Draft,
draft-ietf-uta-tls13-iot-profile-01, 22 February 2021, draft-ietf-uta-tls13-iot-profile-04, 7 March 2022,
<https://www.ietf.org/internet-drafts/draft-ietf-uta- <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
tls13-iot-profile-01.txt>. tls13-iot-profile-04>.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999,
<https://www.rfc-editor.org/info/rfc2522>. <https://www.rfc-editor.org/info/rfc2522>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
skipping to change at page 61, line 9 skipping to change at line 2698
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate [RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate
Compression", RFC 8879, DOI 10.17487/RFC8879, December Compression", RFC 8879, DOI 10.17487/RFC8879, December
2020, <https://www.rfc-editor.org/info/rfc8879>. 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 [ROBUST] Fischlin, M., Günther, F., and C. Janson, "Robust
Channels: Handling Unreliable Networks in the Record Channels: Handling Unreliable Networks in the Record
Layers of QUIC and DTLS 1.3", 15 June 2020, Layers of QUIC and DTLS 1.3", received 15 June 2020, last
revised 22 February 2021,
<https://eprint.iacr.org/2020/718>. <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-11, 7 July 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-11>.
Appendix A. Protocol Data Structures and Constant Values Appendix A. Protocol Data Structures and Constant Values
This section provides the normative protocol types and constants This section provides the normative protocol types and constants
definitions. definitions.
A.1. Record Layer 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 { struct {
opaque content[DTLSPlaintext.length]; ContentType type;
ContentType type; ProtocolVersion legacy_record_version;
uint8 zeros[length_of_padding]; uint16 epoch = 0
} DTLSInnerPlaintext; uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct { struct {
opaque unified_hdr[variable]; opaque content[DTLSPlaintext.length];
opaque encrypted_record[length]; ContentType type;
} DTLSCiphertext; uint8 zeros[length_of_padding];
} DTLSInnerPlaintext;
0 1 2 3 4 5 6 7 struct {
+-+-+-+-+-+-+-+-+ opaque unified_hdr[variable];
|0|0|1|C|S|L|E E| opaque encrypted_record[length];
+-+-+-+-+-+-+-+-+ } DTLSCiphertext;
| 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 { 0 1 2 3 4 5 6 7
uint16 epoch; +-+-+-+-+-+-+-+-+
uint48 sequence_number; |0|0|1|C|S|L|E E|
} RecordNumber; +-+-+-+-+-+-+-+-+
| 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 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),
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 { enum {
HandshakeType msg_type; /* handshake type */ hello_request_RESERVED(0),
uint24 length; /* bytes in message */ client_hello(1),
uint16 message_seq; /* DTLS-required field */ server_hello(2),
uint24 fragment_offset; /* DTLS-required field */ hello_verify_request_RESERVED(3),
uint24 fragment_length; /* DTLS-required field */ new_session_ticket(4),
select (msg_type) { end_of_early_data(5),
case client_hello: ClientHello; hello_retry_request_RESERVED(6),
case server_hello: ServerHello; encrypted_extensions(8),
case end_of_early_data: EndOfEarlyData; request_connection_id(9), /* New */
case encrypted_extensions: EncryptedExtensions; new_connection_id(10), /* New */
case certificate_request: CertificateRequest; certificate(11),
case certificate: Certificate; server_key_exchange_RESERVED(12),
case certificate_verify: CertificateVerify; certificate_request(13),
case finished: Finished; server_hello_done_RESERVED(14),
case new_session_ticket: NewSessionTicket; certificate_verify(15),
case key_update: KeyUpdate; client_key_exchange_RESERVED(16),
} body; finished(20),
} Handshake; certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
uint16 ProtocolVersion; struct {
opaque Random[32]; 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;
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint16 ProtocolVersion;
struct { opaque Random[32];
ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
Random random; uint8 CipherSuite[2]; /* Cryptographic suite selector */
opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS struct {
CipherSuite cipher_suites<2..2^16-2>; ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
opaque legacy_compression_methods<1..2^8-1>; Random random;
Extension extensions<8..2^16-1>; opaque legacy_session_id<0..32>;
} ClientHello; 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 A.3. ACKs
struct { struct {
RecordNumber record_numbers<0..2^16-1>; RecordNumber record_numbers<0..2^16-1>;
} ACK; } ACK;
A.4. Connection ID Management A.4. Connection ID Management
enum { enum {
cid_immediate(0), cid_spare(1), (255) cid_immediate(0), cid_spare(1), (255)
} ConnectionIdUsage; } ConnectionIdUsage;
opaque ConnectionId<0..2^8-1>; opaque ConnectionId<0..2^8-1>;
struct { struct {
ConnectionIds cids<0..2^16-1>; ConnectionId cids<0..2^16-1>;
ConnectionIdUsage usage; ConnectionIdUsage usage;
} NewConnectionId; } NewConnectionId;
struct { struct {
uint8 num_cids; uint8 num_cids;
} RequestConnectionId; } RequestConnectionId;
Appendix B. Analysis of Limits on CCM Usage Appendix B. Analysis of Limits on CCM Usage
TLS [TLS13] and [AEBounds] do not specify limits on key usage for 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 AEAD_AES_128_CCM. However, any AEAD that is used with DTLS requires
limits on use that ensure that both confidentiality and integrity are limits on use that ensure that both confidentiality and integrity are
preserved. This section documents that analysis for preserved. This section documents that analysis for
AEAD_AES_128_CCM. AEAD_AES_128_CCM.
[CCM-ANALYSIS] is used as the basis of this analysis. The results of [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 that analysis are used to derive usage limits that are based on those
chosen in [TLS13]. chosen in [TLS13].
This analysis uses symbols for multiplication (*), division (/), and This analysis uses symbols for multiplication (*), division (/), and
exponentiation (^), plus parentheses for establishing precedence. exponentiation (^), plus parentheses for establishing precedence.
The following symbols are also used: The following symbols are also used:
t: The size of the authentication tag in bits. For this cipher, t t: The size of the authentication tag in bits. For this cipher, t
is 128. is 128.
n: The size of the block function in bits. For this cipher, n is n: The size of the block function in bits. For this cipher, n is
128. 128.
l: The number of blocks in each packet (see below). l: The number of blocks in each packet (see below).
q: The number of genuine packets created and protected by endpoints. q: The number of genuine packets created and protected by endpoints.
This value is the bound on the number of packets that can be This value is the bound on the number of packets that can be
protected before updating keys. protected before updating keys.
v: The number of forged packets that endpoints will accept. This v: The number of forged packets that endpoints will accept. This
value is the bound on the number of forged packets that an value is the bound on the number of forged packets that an
endpoint can reject before updating keys. endpoint can reject before updating keys.
The analysis of AEAD_AES_128_CCM relies on a count of the number of The analysis of AEAD_AES_128_CCM relies on a count of the number of
block operations involved in producing each message. For simplicity, block operations involved in producing each message. For simplicity,
and to match the analysis of other AEAD functions in [AEBounds], this 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 analysis assumes a packet length of 2^10 blocks and a packet size
limit of 2^14 bytes. limit of 2^14 bytes.
For AEAD_AES_128_CCM, the total number of block cipher operations is 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 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 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 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 = twice the maximum length of a record in blocks (that is, 2l = 2^11).
2^11"). This simplification is based on the associated data being This simplification is based on the associated data being limited to
limited to one block. one block.
B.1. Confidentiality Limits B.1. Confidentiality Limits
For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an For confidentiality, Theorem 2 in [CCM-ANALYSIS] establishes that an
attacker gains a distinguishing advantage over an ideal pseudorandom attacker gains a distinguishing advantage over an ideal pseudorandom
permutation (PRP) of no more than: permutation (PRP) of no more than:
(2l * q)^2 / 2^n (2l * q)^2 / 2^n
For a target advantage of 2^-60, which matches that used by [TLS13], For a target advantage in a single-key setting of 2^-60, which
this results in the relation: matches that used by TLS 1.3, as summarized in [AEAD-LIMITS], this
results in the relation:
q <= 2^23 q <= 2^23
That is, endpoints cannot protect more than 2^23 packets with the That is, endpoints cannot protect more than 2^23 packets with the
same set of keys without causing an attacker to gain an larger same set of keys without causing an attacker to gain a larger
advantage than the target of 2^-60. advantage than the target of 2^-60.
B.2. Integrity Limits B.2. Integrity Limits
For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an For integrity, Theorem 1 in [CCM-ANALYSIS] establishes that an
attacker gains an advantage over an ideal PRP of no more than: attacker gains an advantage over an ideal PRP of no more than:
v / 2^t + (2l * (v + q))^2 / 2^n v / 2^t + (2l * (v + q))^2 / 2^n
The goal is to limit this advantage to 2^-57, to match the target in The goal is to limit this advantage to 2^-57, to match the target in
[TLS13]. As "t" and "n" are both 128, the first term is negligible TLS 1.3, as summarized in [AEAD-LIMITS]. As t and n are both 128,
relative to the second, so that term can be removed without a the first term is negligible relative to the second, so that term can
significant effect on the result. This produces the relation: be removed without a significant effect on the result. This produces
the relation:
v + q <= 2^24.5 v + q <= 2^24.5
Using the previously-established value of 2^23 for "q" and rounding, 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 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 cannot attempt to authenticate more than 2^23.5 packets with the same
set of keys without causing an attacker to gain an larger advantage set of keys without causing an attacker to gain a larger advantage
than the target of 2^-57. than the target of 2^-57.
B.3. Limits for AEAD_AES_128_CCM_8 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 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). function, which uses a short authentication tag (that is, t=64).
The confidentiality limits of AEAD_AES_128_CCM_8 are the same as 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 those for AEAD_AES_128_CCM, as this does not depend on the tag
length; see Appendix B.1. length; see Appendix B.1.
The shorter tag length of 64 bits means that the simplification used 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 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 to preserve the same margins as other cipher suites, then the limit
on forgeries is largely dictated by the first term of the advantage on forgeries is largely dictated by the first term of the advantage
formula: formula:
v <= 2^7 v <= 2^7
As this represents attempts to fail authentication, applying this As this represents attempts that fail authentication, applying this
limit might be feasible in some environments. However, applying this limit might be feasible in some environments. However, applying this
limit in an implementation intended for general use exposes limit in an implementation intended for general use exposes
connections to an inexpensive denial of service attack. connections to an inexpensive denial-of-service attack.
This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not 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 suitable for general use. Specifically, TLS_AES_128_CCM_8_SHA256
cannot be used without additional measures to prevent forgery of cannot be used without additional measures to prevent forgery of
records, or to mitigate the effect of forgeries. This might require records, or to mitigate the effect of forgeries. This might require
understanding the constraints that exist in a particular deployment understanding the constraints that exist in a particular deployment
or application. For instance, it might be possible to set a or application. For instance, it might be possible to set a
different target for the advantage an attacker gains based on an different target for the advantage an attacker gains based on an
understanding of the constraints imposed on a specific usage of DTLS. understanding of the constraints imposed on a specific usage of DTLS.
Appendix C. Implementation Pitfalls Appendix C. Implementation Pitfalls
In addition to the aspects of TLS that have been a source of In addition to the aspects of TLS that have been a source of
interoperability and security problems (Section C.3 of [TLS13]), DTLS interoperability and security problems (Appendix C.3 of [TLS13]),
presents a few new potential sources of issues, noted here. DTLS presents a few new potential sources of issues, noted here.
* Do you correctly handle messages received from multiple epochs * Do you correctly handle messages received from multiple epochs
during a key transition? This includes locating the correct key during a key transition? This includes locating the correct key
as well as performing replay detection, if enabled. as well as performing replay detection, if enabled.
* Do you retransmit handshake messages that are not (implicitly or * Do you retransmit handshake messages that are not (implicitly or
explicitly) acknowledged (Section 5.8)? explicitly) acknowledged (Section 5.8)?
* Do you correctly handle handshake message fragments received, * Do you correctly handle handshake message fragments received,
including when they are out of order? including when they are out of order?
* Do you correctly handle handshake messages received out of order? * Do you correctly handle handshake messages received out of order?
This may include either buffering or discarding them. This may include either buffering or discarding them.
* Do you limit how much data you send to a peer before its address * Do you limit how much data you send to a peer before its address
is validated? is validated?
* Do you verify that the explicit record length is contained within * Do you verify that the explicit record length is contained within
the datagram in which it is contained? the datagram in which it is contained?
Appendix D. History Contributors
RFC EDITOR: PLEASE REMOVE THE THIS SECTION
(*) indicates a change that may affect interoperability.
IETF Drafts draft-42
* SHOULD level requirement for the client to offer CID extension.
* Change the default retransmission timer to 1s and allow people to
do otherwise if they have side knowledge.
* Cap any given flight to 10 records
* Don't re-set the timer to the initial value but to 1.5 times the
measured RTT.
* A bunch more clarity about the reliability algorithms and timers
(including changing reset to re-arm)
* Update IANA considerations
draft-40
- Clarified encrypted_record structure in DTLS 1.3 record layer
- Added description of the demultiplexing process
- Added text about the DTLS 1.2 and DTLS 1.3 CID mechanism
- Forbid going from an empty CID to a non-empty CID (*)
- Add warning about certificates and congestion
- Use DTLS style version values, even for DTLS 1.3 (*)
- Describe how to distinguish DTLS 1.2 and DTLS 1.3 connections
- Updated examples
- Included editorial improvements from Ben Kaduk
- Removed stale text about out-of-epoch records
- Added clarifications around when ACKs are sent
- Noted that alerts are unreliable
- Clarify when you can reset the timer
- Indicated that records with bogus epochs should be discarded
- Relax age out text
- Updates to cookie text
- Require that cipher suites define a record number encryption algorithm
- Clean up use of connection and association
- Reference tls-old-versions-deprecate
draft-39 - Updated Figure 4 due to misalignment with Figure 3 content
draft-38 - Ban implicit Connection IDs (*) - ACKs are processed as
the union.
draft-37: - Fix the other place where we have ACK.
draft-36: - Some editorial changes. - Changed the content type to not
conflict with existing allocations (*)
draft-35: - I-D.ietf-tls-dtls-connection-id became a normative
reference - Removed duplicate reference to I-D.ietf-tls-dtls-
connection-id. - Fix figure 11 to have the right numbers andno cookie
in message 1. - Clarify when you can ACK. - Clarify additional data
computation.
draft-33: - Key separation between TLS and DTLS. Issue #72.
draft-32: - Editorial improvements and clarifications.
draft-31: - Editorial improvements in text and figures. - Added
normative reference to ChaCha20 and Poly1305.
draft-30: - Changed record format - Added text about end of early
data - Changed format of the Connection ID Update message - Added
Appendix A "Protocol Data Structures and Constant Values"
draft-29: - Added support for sequence number encryption - Update to
new record format - Emphasize that compatibility mode isn't used.
draft-28: - Version bump to align with TLS 1.3 pre-RFC version.
draft-27: - Incorporated unified header format. - Added support for
CIDs.
draft-04 - 26: - Submissions to align with TLS 1.3 draft versions
draft-03 - Only update keys after KeyUpdate is ACKed.
draft-02 - Shorten the protected record header and introduce an
ultra-short version of the record header. - Reintroduce KeyUpdate,
which works properly now that we have ACK. - Clarify the ACK rules.
draft-01 - Restructured the ACK to contain a list of records and also
be a record rather than a handshake message.
draft-00 - First IETF Draft
Personal Drafts draft-01 - Alignment with version -19 of the TLS 1.3
specification
draft-00
* Initial version using TLS 1.3 as a baseline.
* Use of epoch values instead of KeyUpdate message
* Use of cookie extension instead of cookie field in ClientHello and
HelloVerifyRequest messages
* Added ACK message
* Text about sequence number handling
Appendix E. Working Group Information
RFC EDITOR: PLEASE REMOVE THIS SECTION.
The discussion list for the IETF TLS working group is located at the
e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on
the group and information on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/tls
(https://www1.ietf.org/mailman/listinfo/tls)
Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/tls/current/index.html (https://www.ietf.org/mail-
archive/web/tls/current/index.html)
Appendix F. Contributors
Many people have contributed to previous DTLS versions and they are Many people have contributed to previous DTLS versions, and they are
acknowledged in prior versions of DTLS specifications or in the acknowledged in prior versions of DTLS specifications or in the
referenced specifications. The sequence number encryption concept is referenced specifications.
taken from the QUIC specification. We would like to thank the
authors of the QUIC specification for their work. Felix Guenther and
Martin Thomson contributed the analysis in Appendix B.
In addition, we would like to thank:
* David Benjamin
Google
davidben@google.com
* Thomas Fossati Hanno Becker
Arm Limited Arm Limited
Thomas.Fossati@arm.com Email: Hanno.Becker@arm.com
* Tobias Gondrom David Benjamin
Huawei Google
tobias.gondrom@gondrom.org Email: davidben@google.com
* Felix Günther Thomas Fossati
ETH Zurich Arm Limited
mail@felixguenther.info Email: thomas.fossati@arm.com
* Benjamin Kaduk Tobias Gondrom
Akamai Technologies Huawei
kaduk@mit.edu Email: tobias.gondrom@gondrom.org
* Ilari Liusvaara Felix Günther
Independent ETH Zurich
ilariliusvaara@welho.com Email: mail@felixguenther.info
* Martin Thomson Benjamin Kaduk
Mozilla Akamai Technologies
martin.thomson@gmail.com Email: kaduk@mit.edu
* Christopher A. Wood Ilari Liusvaara
Apple Inc. Independent
cawood@apple.com Email: ilariliusvaara@welho.com
* Yin Xinxing Martin Thomson
Huawei Mozilla
yinxinxing@huawei.com Email: martin.thomson@gmail.com
* Hanno Becker Christopher A. Wood
Arm Limited Cloudflare
Hanno.Becker@arm.com Email: caw@heapingbits.net
Appendix G. Acknowledgements Yin Xinxing
Huawei
Email: yinxinxing@huawei.com
We would like to thank Jonathan Hammell, Bernard Aboba and Andy 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. Cunningham for their review comments.
Additionally, we would like to thank the IESG members for their Additionally, we would like to thank the IESG members for their
review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars review comments: Martin Duke, Erik Kline, Francesca Palombini, Lars
Eggert, Zaheduzzaman Sarker, John Scudder, Eric Vyncke, Robert Eggert, Zaheduzzaman Sarker, John Scudder, Éric Vyncke, Robert
Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin Wilton, Roman Danyliw, Benjamin Kaduk, Murray Kucherawy, Martin
Vigoureux, and Alvaro Retana Vigoureux, and Alvaro Retana.
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
RTFM, Inc. Mozilla
Email: ekr@rtfm.com Email: ekr@rtfm.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
Email: hannes.tschofenig@arm.com Email: hannes.tschofenig@arm.com
Nagendra Modadugu Nagendra Modadugu
Google, Inc. Google, Inc.
Email: nagendra@cs.stanford.edu Email: nagendra@cs.stanford.edu
 End of changes. 297 change blocks. 
963 lines changed or deleted 869 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/