< draft-ietf-tls-dtls13-31.txt   draft-ietf-tls-dtls13-32.txt >
TLS E. Rescorla TLS E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 6347 (if approved) H. Tschofenig Obsoletes: 6347 (if approved) H. Tschofenig
Intended status: Standards Track Arm Limited Intended status: Standards Track Arm Limited
Expires: September 26, 2019 N. Modadugu Expires: January 9, 2020 N. Modadugu
Google, Inc. Google, Inc.
March 25, 2019 July 08, 2019
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
draft-ietf-tls-dtls13-31 draft-ietf-tls-dtls13-32
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 intentionally based on the Transport Layer
Security (TLS) 1.3 protocol and provides equivalent security Security (TLS) 1.3 protocol and provides equivalent security
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5 3. DTLS Design Rationale and Overview . . . . . . . . . . . . . 5
3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Reordering . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Message Size . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Message Size . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 7 3.4. Replay Detection . . . . . . . . . . . . . . . . . . . . 7
4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7 4. The DTLS Record Layer . . . . . . . . . . . . . . . . . . . . 7
4.1. Determining the Header Format . . . . . . . . . . . . . . 11 4.1. Determining the Header Format . . . . . . . . . . . . . . 11
4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11 4.2. Sequence Number and Epoch . . . . . . . . . . . . . . . . 11
4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 11 4.2.1. Processing Guidelines . . . . . . . . . . . . . . . . 11
4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12 4.2.2. Reconstructing the Sequence Number and Epoch . . . . 12
4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 12 4.2.3. Sequence Number Encryption . . . . . . . . . . . . . 13
4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 13 4.3. Transport Layer Mapping . . . . . . . . . . . . . . . . . 14
4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. PMTU Issues . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Record Payload Protection . . . . . . . . . . . . . . . . 16 4.5. Record Payload Protection . . . . . . . . . . . . . . . . 16
4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 16 4.5.1. Anti-Replay . . . . . . . . . . . . . . . . . . . . . 16
4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 16 4.5.2. Handling Invalid Records . . . . . . . . . . . . . . 17
5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 17 5. The DTLS Handshake Protocol . . . . . . . . . . . . . . . . . 17
5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 18 5.1. Denial-of-Service Countermeasures . . . . . . . . . . . . 18
5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 20 5.2. DTLS Handshake Message Format . . . . . . . . . . . . . . 21
5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 22 5.3. ClientHello Message . . . . . . . . . . . . . . . . . . . 22
5.4. Handshake Message Fragmentation and Reassembly . . . . . 23 5.4. Handshake Message Fragmentation and Reassembly . . . . . 23
5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 23 5.5. End Of Early Data . . . . . . . . . . . . . . . . . . . . 24
5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 24 5.6. DTLS Handshake Flights . . . . . . . . . . . . . . . . . 24
5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 28 5.7. Timeout and Retransmission . . . . . . . . . . . . . . . 28
5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 28 5.7.1. State Machine . . . . . . . . . . . . . . . . . . . . 28
5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 30 5.7.2. Timer Values . . . . . . . . . . . . . . . . . . . . 30
5.8. CertificateVerify and Finished Messages . . . . . . . . . 31 5.8. CertificateVerify and Finished Messages . . . . . . . . . 31
5.9. Alert Messages . . . . . . . . . . . . . . . . . . . . . 31 5.9. Alert Messages . . . . . . . . . . . . . . . . . . . . . 31
5.10. Establishing New Associations with Existing Parameters . 31 5.10. Establishing New Associations with Existing Parameters . 31
6. Example of Handshake with Timeout and Retransmission . . . . 32 6. Example of Handshake with Timeout and Retransmission . . . . 32
6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 34 6.1. Epoch Values and Rekeying . . . . . . . . . . . . . . . . 34
7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. ACK Message . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 37 7.1. Sending ACKs . . . . . . . . . . . . . . . . . . . . . . 37
7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 38 7.2. Receiving ACKs . . . . . . . . . . . . . . . . . . . . . 38
8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 38 8. Key Updates . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 38 9. Connection ID Updates . . . . . . . . . . . . . . . . . . . . 38
9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 40 9.1. Connection ID Example . . . . . . . . . . . . . . . . . . 40
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 41 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 43 12. Changes to DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . 43
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.1. Normative References . . . . . . . . . . . . . . . . . . 44 14.1. Normative References . . . . . . . . . . . . . . . . . . 44
14.2. Informative References . . . . . . . . . . . . . . . . . 45 14.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Protocol Data Structures and Constant Values . . . . 47 Appendix A. Protocol Data Structures and Constant Values . . . . 47
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 47 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 47
A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 47 A.2. Handshake Protocol . . . . . . . . . . . . . . . . . . . 47
A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.3. ACKs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.4. Connection ID Management . . . . . . . . . . . . . . . . 49 A.4. Connection ID Management . . . . . . . . . . . . . . . . 49
Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 49 Appendix B. History . . . . . . . . . . . . . . . . . . . . . . 49
Appendix C. Working Group Information . . . . . . . . . . . . . 50 Appendix C. Working Group Information . . . . . . . . . . . . . 50
skipping to change at page 5, line 10 skipping to change at page 5, line 10
- 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.
- session: An association between a client and a server resulting - session: An association between a client and a server resulting
from a handshake. from a handshake.
- server: The endpoint which did not initiate the DTLS connection. - server: The endpoint which did not initiate the DTLS connection.
- CID: Connection ID
The reader is assumed to be familiar with the TLS 1.3 specification The reader is assumed to be familiar with the TLS 1.3 specification
since this document is defined as a delta from TLS 1.3. As in TLS since this document is defined as a delta from TLS 1.3. As in TLS
1.3 the HelloRetryRequest has the same format as a ServerHello 1.3 the HelloRetryRequest has the same format as a ServerHello
message but for convenience we use the term HelloRetryRequest message but for convenience we use the term HelloRetryRequest
throughout this document as if it were a distinct message. throughout this document as if it were a distinct message.
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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 16 bit Length | | 16 bit Length |
| (if present) | | (if present) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: DTLS 1.3 CipherText Header Figure 3: DTLS 1.3 CipherText Header
Fixed Bits: The three high bits of the first byte of the Fixed Bits: The three high bits of the first byte of the
DTLSCiphertext header are set to 001. DTLSCiphertext header are set to 001.
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. means an 8-bit sequence number, 1 means 16-bit.
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 connection ID. The connection ID Connection ID: Variable length CID. The CID concept is described in
concept is described in [DTLS-CID]. An example can be found in [DTLS-CID]. An example can be found in Section 9.1.
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.
skipping to change at page 10, line 49 skipping to change at page 10, line 49
DTLSCiphertext format records without length fields in the same DTLSCiphertext format records without length fields in the same
datagram. datagram.
Omitting the length field MUST only be used for data which is Omitting the length field MUST only be used for data which is
protected with one of the application_traffic_secret values, and not protected with one of the application_traffic_secret values, and not
for messages protected with either [sender]_handshake_traffic_sercret for messages protected with either [sender]_handshake_traffic_sercret
or [sender]_early_traffic_secret values. When using an or [sender]_early_traffic_secret values. When using an
[sender]_application_traffic_secret for message protection, [sender]_application_traffic_secret for message protection,
Implementations MAY include the length field at their discretion. Implementations MAY include the length field at their discretion.
When expanded, the epoch and sequence number can be combined into an
unpacked RecordNumber structure, as shown below:
struct {
uint16 epoch;
uint48 sequence_number;
} RecordNumber;
This 64-bit value is used in the ACK message as well as in the
"record_sequence_number" input to the AEAD function.
The entire header value shown above is used as it appears on the wire The entire header value shown above is used as it appears on the wire
as the additional data value for the AEAD function. as the additional data value for the AEAD function. Note that this
design is different from the additional data calculation for DTLS 1.2
and for DTLS 1.2 with Connection ID.
4.1. Determining the Header Format 4.1. Determining the Header Format
Implementations can distinguish the two header formats by examining Implementations can distinguish the two header formats by examining
the first byte: the first byte:
- If the first byte is alert(21), handshake(22), or ack(proposed, - If the first byte is alert(21), handshake(22), or ack(proposed,
25), the record MUST be interpreted as a DTLSPlaintext record. 25), the record MUST be interpreted as a DTLSPlaintext record.
- If the first byte is any other other value, then receivers MUST - If the first byte is any other value, then receivers MUST check to
check to see if the leading bits of the first byte are 001. If see if the leading bits of the first byte are 001. If so, the
so, the implementation MUST process the record as DTLSCiphertext; implementation MUST process the record as DTLSCiphertext; the true
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.
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 1 may be Because DTLS records could be reordered, a record from epoch M may be
received after epoch 2 has begun. In general, implementations SHOULD received after epoch N (where N > M) has begun. In general,
discard packets from earlier epochs, but if packet loss causes implementations SHOULD discard packets from earlier epochs, but if
noticeable problems implementations MAY choose to retain keying packet loss causes noticeable problems implementations MAY choose to
material from previous epochs for up to the default MSL specified for retain keying material from previous epochs for up to the default MSL
TCP [RFC0793] to allow for packet reordering. (Note that the specified for TCP [RFC0793] to allow for packet reordering. (Note
intention here is that implementers use the current guidance from the that the intention here is that implementers use the current guidance
IETF for MSL, as specified in [RFC0793] or successors not that they from the IETF for MSL, as specified in [RFC0793] or successors not
attempt to interrogate the MSL that the system TCP stack is using.) that they attempt to interrogate the MSL that the system TCP stack is
Until the handshake has completed, implementations MUST accept using.)
packets from the old epoch.
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
packets, though when DTLS is used over reliable transports (e.g., packets, 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 packets handshake completes. Note that TLS's restrictions on when packets
may be sent still apply, and the receiver treats the packets as if may be sent still apply, and the receiver treats the packets as if
they were sent in the right order. In particular, it is still they were sent in the right order.
impermissible to send data prior to completion of the first
handshake.
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 re-key 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.
skipping to change at page 13, line 23 skipping to change at page 13, line 35
[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 Secret value to be used is
described in Section 7.3 of [TLS13]. described in Section 7.3 of [TLS13].
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 sequence number. Decryption is accomplished by of the Mask with the sequence number. Decryption is accomplished by
the same process. the same process.
In some (rare) cases the ciphertext may be less than 16 bytes. This This procedure requires the ciphertext length be at least 16 bytes.
cannot happen with most of the DTLS AEAD algorithms because the Receivers MUST reject shorter records as if they had failed
authentication tag itself is 16 bytes, however some algorithms such deprotection, as described in Section 4.5.2. Senders MUST pad short
as TLS_AES_128_CCM_8_SHA256 have a shorter authentication tag, and in plaintexts out (using the conventional record padding mechanism) in
combination with a short plaintext, the result might be less than 16 order to make a suitable-length ciphertext. Note most of the DTLS
bytes. In this case, implementations MUST pad the plaintext out AEAD algorithms have a 16-byte authentication tag and need no
(using the conventional record padding mechanism) in order to make a padding. However, some algorithms such as TLS_AES_128_CCM_8_SHA256
suitable-length ciphertext. have a shorter authentication tag and may require padding for short
inputs.
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,
which also contains a sequence number. which 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
skipping to change at page 14, line 6 skipping to change at page 14, line 24
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, as defined in this document, do not contain any DTLS records, as defined in this document, do not contain any
association identifiers and applications must arrange to multiplex association identifiers and applications must arrange to multiplex
between associations. With UDP, the host/port number is used to look between associations. With UDP, the host/port number is used to look
up the appropriate security association for incoming records. up the appropriate security association for incoming records.
However, the Connection ID extension defined in [DTLS-CID] adds an However, the CID extension defined in [DTLS-CID] adds an association
association identifier to DTLS records. identifier to DTLS records.
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.
Some transports provide congestion control for traffic carried over Some transports provide congestion control for traffic carried over
them. If the congestion window is sufficiently narrow, DTLS them. If the congestion window is sufficiently narrow, DTLS
skipping to change at page 16, line 25 skipping to change at page 16, line 42
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]. of [RFC4303].
The received packet counter for a session MUST be initialized to zero The received packet counter for a session MUST be initialized to zero
when that session is established. For each received record, the when that session is established. 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
during the lifetime of the session. This check SHOULD happen after during the lifetime of the session. This check SHOULD happen after
deprotecting the packet; otherwise the packet discard might itself deprotecting the packet; otherwise the packet discard might itself
serve as a timing channel for the sequence number. serve as a timing channel for the record number. Note that
decompressing the records number is still a potential timing channel
for the record number, though a less powerful one than whether it 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
receiver does not notify the sender of the window size.) receiver does not notify the sender of the window size.)
The "right" edge of the window represents the highest validated The "right" edge of the window represents the highest validated
sequence number value received on the session. Records that contain sequence number value received on the session. 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. Packets falling within the window are checked against a rejected. Packets falling within the window are checked against a
list of received packets within the window. An efficient means for list of received packets 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 packet is to the right of the the window and is new, or if the packet is to the right of the
window, then the packet is new. window, then the packet is new.
skipping to change at page 17, line 43 skipping to change at page 18, line 15
Note that TLS 1.3 already supports a cookie extension, which is used Note that TLS 1.3 already supports a cookie extension, which is used
to prevent denial-of-service attacks. This DoS prevention mechanism to prevent denial-of-service attacks. This DoS prevention mechanism
is described in more detail below since UDP-based protocols are more is described in more detail below since UDP-based protocols are more
vulnerable to amplification attacks than a connection-oriented vulnerable to amplification attacks than a connection-oriented
transport like TCP that performs return-routability checks as part of transport like TCP that performs return-routability checks 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 Section D.4 of [TLS13]. DTLS servers MUST NOT echo the
"session_id" value from the client and endpoints MUST NOT send "session_id" value from the client and endpoints MUST NOT send
ChangeCipherSpec messages. Note however that implementations MUST ChangeCipherSpec messages.
ignore ChangeCipherSpec messages received in unprotected records.
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 of the connection initiation messages with a forged source of the
victim. The server then sends its response to the victim victim. The server then sends its response to the victim
machine, thus flooding it. Depending on the selected ciphersuite machine, thus flooding it. Depending on the selected parameters
this response message can be quite large, as it is the case for a this response message can be quite large, as it is the case for a
Certificate message. 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. The
HelloRetryRequest message contains a stateless cookie generated using HelloRetryRequest message contains a stateless cookie generated using
the technique of [RFC2522]. The client MUST retransmit the the technique of [RFC2522]. The client MUST retransmit the
skipping to change at page 18, line 43 skipping to change at page 19, line 9
difficult. This mechanism does not provide any defense against DoS difficult. This mechanism does not provide any defense against DoS
attacks mounted from valid IP addresses. attacks mounted from valid IP addresses.
The DTLS 1.3 specification changes the way how cookies are exchanged The DTLS 1.3 specification changes the way how cookies are exchanged
compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message
and conveys the cookie to the client via an extension. The client and 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 hand
used a separate message, namely the HelloVerifyRequest, to pass a used a separate message, namely the HelloVerifyRequest, to pass a
cookie to the client and did not utilize the extension mechanism. cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reason 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 1.3
compliant server implementation. compliant server implementation.
The exchange is shown in Figure 5. Note that the figure focuses on The exchange is shown in Figure 5. 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 ------>
skipping to change at page 20, line 29 skipping to change at page 20, line 42
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, the server MAY be
configured not to perform a cookie exchange. The default SHOULD be configured not to perform a cookie exchange. The default SHOULD be
that the exchange is performed, however. In addition, the server MAY that the exchange is performed, however. In addition, the server MAY
choose not to do a cookie exchange when a session is resumed. choose not to do a cookie exchange when a session is resumed.
Clients MUST be prepared to do a cookie exchange with every Clients MUST be prepared to do a cookie exchange with every
handshake. handshake.
If a server receives a ClientHello with an invalid cookie, it MUST If a server receives a ClientHello with an invalid cookie, it MUST
NOT respond with a HelloRetryRequest. Restarting the handshake from NOT terminate the handshake with an "illegal_parameter" alert. This
scratch, without a cookie, allows the client to recover from a allows the client to restart the connection from scratch without a
situation where it obtained a cookie that cannot be verified by the cookie.
server. As described in Section 4.1.4 of [TLS13], clients SHOULD
also abort the handshake with an "unexpected_message" alert in As described in Section 4.1.4 of [TLS13], clients MUST abort the
response to any second HelloRetryRequest which was sent in the same handshake with an "unexpected_message" alert in response to any
connection (i.e., where the ClientHello was itself in response to a second HelloRetryRequest which was sent in the same connection (i.e.,
HelloRetryRequest). where the ClientHello was itself in response to a HelloRetryRequest).
5.2. DTLS Handshake Message Format 5.2. DTLS Handshake Message Format
In order to support message loss, reordering, and message In order to support message loss, reordering, and message
fragmentation, DTLS modifies the TLS 1.3 handshake header: fragmentation, DTLS modifies the TLS 1.3 handshake header:
enum { enum {
client_hello(1), client_hello(1),
server_hello(2), server_hello(2),
new_session_ticket(4), new_session_ticket(4),
skipping to change at page 22, line 45 skipping to change at page 22, line 51
legacy_version: In previous versions of DTLS, this field was used legacy_version: In previous versions of DTLS, this field was used
for version negotiation and represented the highest version number for version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable intolerance" in which the server rejects an otherwise acceptable
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. version number for DTLS 1.2. The version fields for DTLS 1.0 and
DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but
the version field for DTLS 1.3 is 0x0304.
random: Same as for TLS 1.3. random: Same as for TLS 1.3.
legacy_session_id: Same as for TLS 1.3. legacy_session_id: Same as for TLS 1.3.
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. field to zero length. If a DTLS 1.3 ClientHello is received with
any other value in this field, the server MUST abort the handshake
with an "illegal_parameter" alert.
cipher_suites: Same as for TLS 1.3. cipher_suites: Same as for TLS 1.3.
legacy_compression_methods: Same as for TLS 1.3. legacy_compression_methods: Same as for TLS 1.3.
extensions: Same as for TLS 1.3. extensions: Same as for TLS 1.3.
5.4. Handshake Message Fragmentation and Reassembly 5.4. Handshake Message Fragmentation and Reassembly
Each DTLS message MUST fit within a single transport layer datagram. Each DTLS message MUST fit within a single transport layer datagram.
However, handshake messages are potentially bigger than the maximum However, handshake messages are potentially bigger than the maximum
record size. Therefore, DTLS provides a mechanism for fragmenting a record size. Therefore, DTLS provides a mechanism for fragmenting a
handshake message over a number of records, each of which can be handshake message over a number of records, each of which can be
transmitted separately, thus avoiding IP fragmentation. transmitted separately, 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. These ranges MUST message into a series of N contiguous data ranges. The ranges MUST
NOT be larger than the maximum handshake fragment size and MUST NOT overlap. The sender then creates N handshake messages, all with
jointly contain the entire handshake message. The ranges MUST NOT the same message_seq value as the original handshake message. Each
overlap. The sender then creates N handshake messages, all with the new message is labeled with the fragment_offset (the number of bytes
same message_seq value as the original handshake message. Each new
message is labeled with the fragment_offset (the number of bytes
contained in previous fragments) and the fragment_length (the length contained in previous fragments) and the fragment_length (the length
of this fragment). The length field in all messages is the same as of this fragment). The length field in all messages is the same as
the length field of the original message. An unfragmented message is the length field of the original message. An unfragmented message is
a degenerate case with fragment_offset=0 and fragment_length=length. a degenerate case with fragment_offset=0 and fragment_length=length.
Each range MUST be delivered in a single packet.
When a DTLS implementation receives a handshake message fragment, it When a DTLS implementation receives a handshake message fragment, it
MUST buffer it until it has the entire handshake message. DTLS MUST buffer it until it has the entire handshake message. DTLS
implementations MUST be able to handle overlapping fragment ranges. implementations MUST be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes. fragment sizes if the PMTU estimate 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
skipping to change at page 24, line 7 skipping to change at page 24, line 15
5.5. End Of Early Data 5.5. End Of Early Data
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 aggressively age out the epoch 1 keys upon receiving the first SHOULD aggressively age out the epoch 1 keys upon receiving the first
epoch 2 record and SHOULD NOT accept epoch 1 data after the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first
epoch 3 record is received. epoch 3 record is received. (See Section 6.1 for the definitions of
each epoch.)
5.6. DTLS Handshake Flights 5.6. DTLS Handshake Flights
DTLS messages are grouped into a series of message flights, according DTLS messages are grouped into a series of message flights, according
to the diagrams below. to the diagrams below.
Client Server Client Server
ClientHello +----------+ ClientHello +----------+
+ key_share* | Flight 1 | + key_share* | Flight 1 |
skipping to change at page 27, line 22 skipping to change at page 27, line 22
(Application Data*) --------> (Application Data*) -------->
ServerHello ServerHello
+ pre_shared_key + pre_shared_key
+ key_share* +----------+ + key_share* +----------+
{EncryptedExtensions} | Flight 2 | {EncryptedExtensions} | Flight 2 |
{Finished} +----------+ {Finished} +----------+
<-------- [Application Data*] <-------- [Application Data*]
+----------+ +----------+
(EndOfEarlyData) | Flight 3 | {Finished} --------> | Flight 3 |
{Finished} --------> +----------+ [Application Data*] +----------+
[Application Data*]
+----------+ +----------+
<-------- [ACK] | Flight 4 | <-------- [ACK] | Flight 4 |
[Application Data*] +----------+ [Application Data*] +----------+
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 8: Message flights for the Zero-RTT handshake Figure 8: Message flights for the Zero-RTT handshake
Client Server Client Server
skipping to change at page 29, line 39 skipping to change at page 29, line 39
state if this is the last flight in the handshake. Or, if the state if this is the last flight in the handshake. Or, if the
implementation expects to receive more messages, it sets a retransmit implementation expects to receive more messages, it sets a retransmit
timer and then enters the WAITING state. timer and then 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, resets the the SENDING state, where it retransmits the flight, resets the
retransmit timer, and returns to the WAITING state. retransmit timer, and returns to the WAITING state.
2. The implementation reads a 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, resets the retransmits the unacked portion of the flight, resets the
retransmit timer, and returns to the WAITING state. Upon retransmit timer, and returns to the WAITING state. Upon
receiving an ACK for a complete flight, the implementation 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 the implementation transitions to the SENDING state, where it
skipping to change at page 30, line 45 skipping to change at page 30, line 45
5.7.2. Timer Values 5.7.2. Timer Values
Though timer values are the choice of the implementation, mishandling Though timer values are the choice of the implementation, mishandling
of the timer can lead to serious congestion problems; for example, if of the timer can lead to serious congestion problems; for example, if
many instances of a DTLS time out early and retransmit too quickly on many instances of a DTLS time out early and retransmit too quickly on
a congested link. Implementations SHOULD use an initial timer value a congested link. Implementations SHOULD use an initial timer value
of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double
the value at each retransmission, up to no less than the RFC 6298 the value at each retransmission, up to no less than the RFC 6298
maximum of 60 seconds. Application specific profiles, such as those maximum of 60 seconds. Application specific profiles, such as those
used for the Internet of Things environment, may recommend longer used for the Internet of Things environment, may recommend longer
timer values. Note that a 100 msec timer is recommend rather than timer values. Note that a 100 msec timer is recommended rather than
the 3-second RFC 6298 default in order to improve latency for time- the 3-second RFC 6298 default in order to improve latency for time-
sensitive applications. Because DTLS only uses retransmission for sensitive applications. Because DTLS only uses retransmission for
handshake and not dataflow, the effect on congestion should be handshake and not dataflow, the effect on congestion should be
minimal. minimal.
Implementations SHOULD retain the current timer value until a Implementations SHOULD retain the current timer value until a
transmission without loss occurs, at which time the value may be transmission without loss occurs, at which time the value may be
reset to the initial value. After a long period of idleness, no less reset to the initial value. After a long period of idleness, no less
than 10 times the current timer value, implementations may reset the than 10 times the current timer value, implementations may reset the
timer to the initial value. timer to the initial value.
skipping to change at page 32, line 7 skipping to change at page 32, line 7
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 packet is from. For instance, if the client performs a given packet 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 new
handshake, it may not be possible to tell which connection a given handshake, it may not be possible to tell which connection a given
protected record is for. In these cases, trial decryption MAY be protected record is for. In these cases, trial decryption MAY be
necessary, though implementations could also use some sort of necessary, though implementations could also use some sort of CID,
connection identifier, such as the one specified in such as the one specified in [I-D.ietf-tls-dtls-connection-id].
[I-D.ietf-tls-dtls-connection-id].
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. retransmissions.
Client Server Client Server
------ ------ ------ ------
Record 0 --------> Record 0 -------->
skipping to change at page 34, line 26 skipping to change at page 34, line 26
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. This includes early data sent from client_early_traffic_secret. Note this epoch is skipped if
by the client and the EndOfEarlyData message. 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, post-handshake are
protected under the appropriate application traffic key and are protected under the appropriate application traffic key and are
not included in this category. 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 traffic_secret_0. This may include handshake from the initial [sender]_application_traffic_secret_0. This may
messages, such as post-handshake messages (e.g., a include handshake messages, such as post-handshake messages (e.g.,
NewSessionTicket message). a NewSessionTicket message).
- epoch value (4 to 2^16-1) is used for payloads protected using - epoch value (4 to 2^16-1) is used for payloads protected using
keys from the 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 payload with an epoch value for which Implementations that receive a payload with an epoch value for which
no corresponding cipher state can be determined MUST generate a no corresponding cipher state can be determined MUST generate a
"unexpected_message" alert. For example, client incorrectly uses "unexpected_message" alert. For example, client incorrectly uses
epoch value 5 when sending early application data in a 0-RTT epoch value 5 when sending early application data in a 0-RTT
exchange. A server will not be able to compute the appropriate keys exchange. A server will not be able to compute the appropriate keys
and will therefore have to respond with an alert. and will therefore have to respond with an alert.
skipping to change at page 36, line 33 skipping to change at page 36, line 33
7. ACK Message 7. ACK Message
The ACK message is used by an endpoint to indicate handshake- The ACK message is used by an endpoint to indicate handshake-
containing the TLS records it has received from the other side. ACK containing the TLS records it has received from the other side. ACK
is not a handshake message but is rather a separate content type, is not a handshake message but is rather a separate content type,
with code point TBD (proposed, 25). This avoids having ACK being with code point TBD (proposed, 25). This avoids having ACK being
added to the handshake transcript. Note that ACKs can still be sent added to the handshake transcript. Note that ACKs can still be sent
in the same UDP datagram as handshake records. in the same UDP datagram as handshake records.
struct { struct {
uint64 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, in in the current flight which the endpoint has received, in
numerically increasing order. ACKs only cover the current numerically increasing order. ACKs only cover the current
outstanding flight (this is possible because DTLS is generally a outstanding flight (this is possible because DTLS is generally a
lockstep protocol). Thus, an ACK from the server would not cover lockstep protocol). Thus, an ACK from the server would not cover
both the ClientHello and the client's Certificate. both the ClientHello and the client's Certificate.
Implementations can accomplish this by clearing their ACK list Implementations can accomplish this by clearing their ACK list
upon receiving the start of the next flight. upon receiving the start of the next flight.
skipping to change at page 38, line 48 skipping to change at page 38, line 48
it. Implementations MUST retain the ability to ACK the KeyUpdate for it. Implementations MUST retain the ability to ACK the KeyUpdate for
up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- up to 2MSL. It is RECOMMENDED that they do so by retaining the pre-
update keying material, but they MAY do so by responding to messages update keying material, but they MAY do so by responding to messages
which appear to be out-of-epoch with a canned ACK message; in this which appear to be out-of-epoch with a canned ACK message; in this
case, implementations SHOULD rate limit how often they send such case, implementations SHOULD rate limit how often they send such
ACKs. ACKs.
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 [DTLS-CID], either side can send a new connection ID which extension [DTLS-CID], either side can send a new CID which it wishes
it wishes the other side to use in a NewConnectionId message. the other side to use in a NewConnectionId 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>; ConnectionIds cids<0..2^16-1>;
ConnectionIdUsage usage; ConnectionIdUsage usage;
skipping to change at page 39, line 47 skipping to change at page 39, line 47
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_cid CIDs soon
as possible. Endpoints MUST NOT send a RequestConnectionId message as possible. Endpoints MUST NOT send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that when an existing request is still unfulfilled; this implies that
endpoints needs to request new CIDs well in advance. An endpoint MAY endpoints needs to request new CIDs well in advance. An endpoint MAY
ignore requests, which it considers excessive (though they MUST be ignore requests, which it considers excessive (though they MUST be
acknowledged as usual). acknowledged as usual).
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 connection ID. If an implementation receives these negotiate a CID. If an implementation receives these messages when
messages when connection IDs were not negotiated, it MUST abort the CIDs were not negotiated, it MUST abort the connection with an
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 connection Below is an example exchange for DTLS 1.3 using a single CID in each
id in each direction. direction.
Note: The connection_id extension is defined in [DTLS-CID], which is Note: The connection_id extension is defined in [DTLS-CID], which is
used in ClientHello and ServerHello messages. used in ClientHello and ServerHello messages.
Client Server Client Server
------ ------ ------ ------
ClientHello ClientHello
(connection_id=5) (connection_id=5)
--------> -------->
skipping to change at page 41, line 44 skipping to change at page 41, line 44
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 13: Example DTLS 1.3 Exchange with Connection IDs Figure 13: Example DTLS 1.3 Exchange with CIDs
If no CID is negotiated, then the receiver MUST reject any records it
receives that contain a CID.
10. Application Data Protocol 10. Application Data Protocol
Application data messages are carried by the record layer and are Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
11. Security Considerations 11. Security Considerations
Security issues are discussed primarily in [TLS13]. Security issues are discussed primarily in [TLS13].
skipping to change at page 42, line 20 skipping to change at page 42, line 26
of denial of service. DTLS includes a cookie exchange designed to of denial of service. DTLS includes a cookie exchange designed to
protect against denial of service. However, implementations that do protect against denial of service. However, implementations that do
not use this cookie exchange are still vulnerable to DoS. In not use this cookie exchange are still vulnerable to DoS. In
particular, DTLS servers that do not use the cookie exchange may be particular, DTLS servers that do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not used as attack amplifiers even if they themselves are not
experiencing DoS. Therefore, DTLS servers SHOULD use the cookie experiencing DoS. Therefore, DTLS servers SHOULD use the cookie
exchange unless there is good reason to believe that amplification is exchange unless there is good reason to believe that amplification is
not a threat in their environment. Clients MUST be prepared to do a not a threat in their environment. Clients MUST be prepared to do a
cookie exchange with every handshake. cookie exchange with every handshake.
DTLS implementations MUST NOT update their sending address in
response to packets from a different address unless they first
perform some reachability test; no such test is defined in this
specification. Even with such a test, An on-path adversary can also
black-hole traffic or create a reflection attack against third
parties because a DTLS peer has no means to distinguish a genuine
address update event (for example, due to a NAT rebinding) from one
that is malicious. This attack is of concern when there is a large
asymmetry of request/response message sizes.
With the exception of order protection and non-replayability, the 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.
If implementations process out-of-epoch records as recommended in If implementations process out-of-epoch records as recommended in
Section 8, then this creates a denial of service risk since an Section 8, then this creates a denial of service risk since an
adversary could inject packets with fake epoch values, forcing the adversary could inject packets with fake epoch values, forcing the
recipient to compute the next-generation application_traffic_secret recipient to compute the next-generation application_traffic_secret
using the HKDF-Expand-Label construct to only find out that the using the HKDF-Expand-Label construct to only find out that the
message was does not pass the AEAD cipher processing. The impact of message was does not pass the AEAD cipher processing. The impact of
this attack is small since the HKDF-Expand-Label only performs this attack is small since the HKDF-Expand-Label only performs
symmetric key hashing operations. Implementations which are symmetric key hashing operations. Implementations which are
concerned about this form of attack can discard out-of-epoch records. concerned about this form of attack can discard out-of-epoch records.
The security and privacy properties of the connection ID for DTLS 1.3 The security and privacy properties of the CID for DTLS 1.3 builds on
builds on top of what is described in [DTLS-CID]. There are, top of what is described in [DTLS-CID]. There are, however, several
however, several improvements: improvements:
- The use of the Post-Handshake message allows the client and the - The use of the Post-Handshake message allows the client and the
server to update their connection IDs and those values are server to update their CIDs and those values are exchanged with
exchanged with confidentiality protection. confidentiality protection.
- With multi-homing, an adversary is able to correlate the - With multi-homing, an adversary is able to correlate the
communication interaction over the two paths, which adds further communication interaction over the two 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 connection IDs whenever they change SHOULD attempt to use fresh CIDs whenever they change local
local addresses or ports (though this is not always possible to addresses or ports (though this is not always possible to detect).
detect). The RequestConnectionId message can be used to ask for The RequestConnectionId message can be used by a peer to ask for
new IDs in order to ensure that you have a pool of suitable IDs. new CIDs to ensure that a pool of suitable CIDs is available.
- Switching connection ID based on certain events, or even - Switching CID based on certain events, or even regularly, helps
regularly, helps against tracking by onpath adversaries but the against tracking by on-path adversaries but the sequence numbers
sequence numbers can still allow linkability. For this reason can still allow linkability. For this reason this specification
this specification defines an algorithm for encrypting sequence defines an algorithm for encrypting sequence numbers, see
numbers, see Section 4.2.3. Section 4.2.3. Note that sequence number encryption is used for
all encrypted DTLS 1.3 records irrespectively of the use of a CID.
- Since the DTLS 1.3 exchange encrypts handshake messages much - DTLS 1.3 encrypts handshake messages much earlier than in previous
earlier than in previous DTLS versions information identifying the DTLS versions. Therefore, less information identifying the DTLS
DTLS client, such as the client certificate, less information is client, such as the client certificate, is available to an on-path
available to an on-path adversary. adversary.
12. Changes to DTLS 1.2 12. Changes to DTLS 1.2
Since TLS 1.3 introduces a large number of changes to TLS 1.2, the Since TLS 1.3 introduces a large number of changes to TLS 1.2, the
list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this list of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this
reason this section focuses on the most important changes only. reason this section focuses on the most important changes only.
- New handshake pattern, which leads to a shorter message exchange - New handshake pattern, which leads to a shorter message exchange
- Support for AEAD-only ciphers - Only AEAD ciphers are supported. Additional data calculation has
been simplified.
- Removed support for weaker and older cryptographic algorithms
- HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest - HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest
- More flexible ciphersuite negotiation - More flexible ciphersuite 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
- Removed support for weaker and older cryptographic algorithms
- Improved version negotiation - Improved version negotiation
- Optimized record layer encoding and thereby its size - Optimized record layer encoding and thereby its size
- Added connection ID functionality - Added CID functionality
- Sequence numbers are encrypted. - Sequence numbers are encrypted.
13. IANA Considerations 13. IANA Considerations
IANA is requested to allocate a new value in the "TLS ContentType" IANA is requested to allocate a new value 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, with content type
25. IANA is requested to reserve the content type range 32-63 so 25. IANA is requested to reserve the content type range 32-63 so
that content types in this range are not allocated. that content types in this range are not allocated.
skipping to change at page 45, line 14 skipping to change at page 45, line 33
[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>.
14.2. Informative References 14.2. Informative References
[DTLS-CID] [DTLS-CID]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-04 (work in progress), March 2019. id-06 (work in progress), July 2019.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-04 (work in progress), March 2019. id-06 (work in progress), July 2019.
[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 49, line 12 skipping to change at page 49, line 12
opaque legacy_session_id<0..32>; opaque legacy_session_id<0..32>;
opaque legacy_cookie<0..2^8-1>; // DTLS opaque legacy_cookie<0..2^8-1>; // DTLS
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>; opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>; Extension extensions<8..2^16-1>;
} ClientHello; } ClientHello;
A.3. ACKs A.3. ACKs
struct { struct {
uint64 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>;
skipping to change at page 49, line 36 skipping to change at page 49, line 36
} NewConnectionId; } NewConnectionId;
struct { struct {
uint8 num_cids; uint8 num_cids;
} RequestConnectionId; } RequestConnectionId;
Appendix B. History Appendix B. History
RFC EDITOR: PLEASE REMOVE THE THIS SECTION RFC EDITOR: PLEASE REMOVE THE THIS SECTION
IETF Drafts draft-29: - Added support for sequence number encryption IETF Drafts
- Update to new record format - Emphasize that compatibility mode
isn't used. 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-28: - Version bump to align with TLS 1.3 pre-RFC version.
draft-27: - Incorporated unified header format. - Added support for draft-27: - Incorporated unified header format. - Added support for
connection IDs. CIDs.
draft-04 - 26: - Submissions to align with TLS 1.3 draft versions draft-04 - 26: - Submissions to align with TLS 1.3 draft versions
draft-03 - Only update keys after KeyUpdate is ACKed. draft-03 - Only update keys after KeyUpdate is ACKed.
draft-02 - Shorten the protected record header and introduce an draft-02 - Shorten the protected record header and introduce an
ultra-short version of the record header. - Reintroduce KeyUpdate, ultra-short version of the record header. - Reintroduce KeyUpdate,
which works properly now that we have ACK. - Clarify the ACK rules. which works properly now that we have ACK. - Clarify the ACK rules.
draft-01 - Restructured the ACK to contain a list of packets and also draft-01 - Restructured the ACK to contain a list of packets and also
skipping to change at page 50, line 46 skipping to change at page 51, line 9
Appendix D. Contributors Appendix D. 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. The sequence number encryption concept is
taken from the QUIC specification. We would like to thank the taken from the QUIC specification. We would like to thank the
authors of the QUIC specification for their work. authors of the QUIC specification for their work.
In addition, we would like to thank: In addition, we would like to thank:
* David Benjamin
Google
davidben@google.com
* Thomas Fossati
Nokia
thomas.fossati@nokia.com
* Tobias Gondrom
Huawei
tobias.gondrom@gondrom.org
* Ilari Liusvaara * Ilari Liusvaara
Independent Independent
ilariliusvaara@welho.com ilariliusvaara@welho.com
* Martin Thomson * Martin Thomson
Mozilla Mozilla
martin.thomson@gmail.com martin.thomson@gmail.com
* Christopher A. Wood
Apple Inc.
cawood@apple.com
* Yin Xinxing * Yin Xinxing
Huawei Huawei
yinxinxing@huawei.com yinxinxing@huawei.com
* Thomas Fossati
Nokia
thomas.fossati@nokia.com
* Tobias Gondrom
Huawei
tobias.gondrom@gondrom.org
Authors' Addresses Authors' Addresses
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
 End of changes. 61 change blocks. 
128 lines changed or deleted 176 lines changed or added

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