draft-ietf-tsvwg-dtls-over-sctp-bis-01.txt   draft-ietf-tsvwg-dtls-over-sctp-bis-02.txt 
TSVWG M. Westerlund TSVWG M. Westerlund
Internet-Draft J. Preuß Mattsson Internet-Draft J. Preuß Mattsson
Obsoletes: 6083 (if approved) C. Porfiri Obsoletes: 6083 (if approved) C. Porfiri
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: 13 January 2022 M. Tüxen Expires: 28 April 2022 25 October 2021
Münster Univ. of Appl. Sciences
12 July 2021
Datagram Transport Layer Security (DTLS) over Stream Control Datagram Transport Layer Security (DTLS) over Stream Control
Transmission Protocol (SCTP) Transmission Protocol (SCTP)
draft-ietf-tsvwg-dtls-over-sctp-bis-01 draft-ietf-tsvwg-dtls-over-sctp-bis-02
Abstract Abstract
This document describes a proposed update for the usage of the This document describes the usage of the Datagram Transport Layer
Datagram Transport Layer Security (DTLS) protocol to protect user Security (DTLS) protocol to protect user messages sent over the
messages sent over the Stream Control Transmission Protocol (SCTP). Stream Control Transmission Protocol (SCTP). It is an improved
update of the existing rfc6083.
DTLS over SCTP provides mutual authentication, confidentiality, DTLS over SCTP provides mutual authentication, confidentiality,
integrity protection, and replay protection for applications that use integrity protection, and replay protection for applications that use
SCTP as their transport protocol and allows client/server SCTP as their transport protocol and allows client/server
applications to communicate in a way that is designed to give applications to communicate in a way that is designed to give
communications privacy and to prevent eavesdropping and detect communications privacy and to prevent eavesdropping and detect
tampering or message forgery. tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport Applications using DTLS over SCTP can use almost all transport
features provided by SCTP and its extensions. This document intends features provided by SCTP and its extensions. This document intends
to obsolete RFC 6083 and removes the 16 kB limitation on user message to obsolete RFC 6083 and removes the 16 kB limitation due to DTLS on
size by defining a secure user message fragmentation so that multiple user message size by defining a secure user message fragmentation so
DTLS records can be used to protect a single user message. It that multiple DTLS records can be used to protect a single user
further updates the DTLS versions to use, as well as the HMAC message. It further updates the DTLS versions to use, as well as the
algorithms for SCTP-AUTH, and simplifies secure implementation by HMAC algorithms for SCTP-AUTH, and simplifies secure implementation
some stricter requirements on the establishment procedures. by some stricter requirements on the establishment procedures.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the TSVWG Working Group Discussion of this document takes place on the TSVWG Working Group
mailing list (tsvwg@ietf.org), which is archived at mailing list (tsvwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/tsvwg/. https://mailarchive.ietf.org/arch/browse/tsvwg/.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
skipping to change at line 62 skipping to change at page 2, line 20
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 13 January 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Comparison with TLS for SCTP 1.1.1. Comparison with TLS for SCTP . . . . . . . . . . . . 5
1.1.2. Changes from RFC 6083 1.1.2. Changes from RFC 6083 . . . . . . . . . . . . . . . . 5
1.2. DTLS Version 1.2. DTLS Version . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Abbreviations 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. DTLS Considerations 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version of DTLS 3.1. Version of DTLS . . . . . . . . . . . . . . . . . . . . . 8
3.2. Cipher Suites and Cryptographic Parameters 3.2. Cipher Suites and Cryptographic Parameters . . . . . . . 8
3.3. Message Sizes 3.3. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Replay Protection 3.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 9
3.5. Path MTU Discovery 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 9
3.6. Retransmission of Messages 3.6. Retransmission of Messages . . . . . . . . . . . . . . . 10
4. SCTP Considerations
4.1. Mapping of DTLS Records 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.2. DTLS Connection Handling 4.1. Mapping of DTLS Records . . . . . . . . . . . . . . . . . 10
4.3. Payload Protocol Identifier Usage 4.2. DTLS Connection Handling . . . . . . . . . . . . . . . . 12
4.4. Stream Usage 4.3. Payload Protocol Identifier Usage . . . . . . . . . . . . 13
4.5. Chunk Handling 4.4. Stream Usage . . . . . . . . . . . . . . . . . . . . . . 13
4.6. SCTP-AUTH Hash Function 4.5. Chunk Handling . . . . . . . . . . . . . . . . . . . . . 13
4.7. Renegotiation 4.6. SCTP-AUTH Hash Function . . . . . . . . . . . . . . . . . 14
4.7.1. DTLS 1.2 Considerations 4.7. Parallel DTLS connections . . . . . . . . . . . . . . . . 14
4.7.2. DTLS 1.3 Considerations 4.8. Renegotiation and KeyUpdate . . . . . . . . . . . . . . . 16
4.8. DTLS Epochs 4.8.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 17
4.8.1. DTLS 1.2 Considerations 4.8.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 17
4.8.2. DTLS 1.3 Considerations 4.9. DTLS Epochs . . . . . . . . . . . . . . . . . . . . . . . 17
4.9. Handling of Endpoint-Pair Shared Secrets 4.9.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 17
4.9.1. DTLS 1.2 Considerations 4.9.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 17
4.9.2. DTLS 1.3 Considerations 4.10. Handling of Endpoint-Pair Shared Secrets . . . . . . . . 18
4.10. Shutdown 4.10.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . 18
5. DTLS over SCTP Service 4.10.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . 18
5.1. Adaptation Layer Indication in INIT/INIT-ACK 4.11. Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. DTLS over SCTP Initialization 5. DTLS over SCTP Service . . . . . . . . . . . . . . . . . . . 19
5.3. Client Use Case 5.1. Adaptation Layer Indication in INIT/INIT-ACK . . . . . . 19
5.4. Server Use Case 5.2. DTLS over SCTP Initialization . . . . . . . . . . . . . . 19
5.5. RFC 6083 Fallback 5.3. Client Use Case . . . . . . . . . . . . . . . . . . . . . 20
6. Socket API Considerations 5.4. Server Use Case . . . . . . . . . . . . . . . . . . . . . 20
5.5. RFC 6083 Fallback . . . . . . . . . . . . . . . . . . . . 20
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 21
6.1. Socket Option to Get the HMAC Identifier being Sent 6.1. Socket Option to Get the HMAC Identifier being Sent
(SCTP_SEND_HMAC_IDENT) (SCTP_SEND_HMAC_IDENT) . . . . . . . . . . . . . . . . . 21
6.2. Exposing the HMAC Identifiers being Received 6.2. Exposing the HMAC Identifiers being Received . . . . . . 22
6.3. Socket Option to Expose HMAC Identifier Usage 6.3. Socket Option to Expose HMAC Identifier Usage
(SCTP_EXPOSE_HMAC_IDENT_CHANGES) (SCTP_EXPOSE_HMAC_IDENT_CHANGES) . . . . . . . . . . . . 23
7. IANA Considerations 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. TLS Exporter Label 7.1. TLS Exporter Label . . . . . . . . . . . . . . . . . . . 23
7.2. SCTP Adaptation Layer Indication Code Point 7.2. SCTP Adaptation Layer Indication Code Point . . . . . . . 23
8. Security Considerations 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8.1. Cryptographic Considerations 8.1. Cryptographic Considerations . . . . . . . . . . . . . . 24
8.2. Downgrade Attacks 8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 26
8.3. Authentication and Policy Decisions 8.3. Authentication and Policy Decisions . . . . . . . . . . . 26
8.4. Privacy Considerations 8.4. Privacy Considerations . . . . . . . . . . . . . . . . . 26
8.5. Pervasive Monitoring 8.5. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27
9. Acknowledgments 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
10. References 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2. Informative References 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Motivation for Changes 11.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses Appendix A. Motivation for Changes . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This document describes the usage of the Datagram Transport Layer This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS
1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission 1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission
Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks
for SCTP (SCTP-AUTH) [RFC4895]. for SCTP (SCTP-AUTH) [RFC4895].
skipping to change at line 175 skipping to change at page 4, line 40
* a large number of unidirectional and bidirectional streams. * a large number of unidirectional and bidirectional streams.
* ordered and unordered delivery of SCTP user messages. * ordered and unordered delivery of SCTP user messages.
* the partial reliability extension as defined in [RFC3758]. * the partial reliability extension as defined in [RFC3758].
* the dynamic address reconfiguration extension as defined in * the dynamic address reconfiguration extension as defined in
[RFC5061]. [RFC5061].
* large user messages. * User messages of a size up to 2^64-1.
The method described in this document requires that the SCTP The method described in this document requires that the SCTP
implementation supports the optional feature of fragmentation of SCTP implementation supports the optional feature of fragmentation of SCTP
user messages as defined in [RFC4960]. The implementation is also user messages as defined in [RFC4960]. The implementation is
required to have an SCTP API (for example the one described in required to have an SCTP API (for example the one described in
[RFC6458]) that supports partial user message delivery and also [RFC6458]) that supports partial user message delivery and also
recommended that I-DATA chunks as defined in [RFC8260] is used to recommended that I-DATA chunks as defined in [RFC8260] is used to
efficiently implement and support larger user messages. efficiently implement and support larger user messages.
To simplify implementation and reduce the risk for security holes, To simplify implementation and reduce the risk for security holes,
limitations have been defined such that STARTTLS as specified in limitations have been defined such that STARTTLS as specified in
[RFC3788] is no longer supported. [RFC3788] is no longer supported.
1.1.1. Comparison with TLS for SCTP 1.1.1. Comparison with TLS for SCTP
skipping to change at line 210 skipping to change at page 5, line 26
* It only supports the usage of the same number of streams in both * It only supports the usage of the same number of streams in both
directions. directions.
* It uses a TLS connection for every bidirectional stream, which * It uses a TLS connection for every bidirectional stream, which
requires a substantial amount of resources and message exchanges requires a substantial amount of resources and message exchanges
if a large number of streams is used. if a large number of streams is used.
1.1.2. Changes from RFC 6083 1.1.2. Changes from RFC 6083
The DTLS over SCTP solution defined in RFC 6083 had the following The DTLS over SCTP solution defined in RFC 6083 had the following
limitation: limitations:
* The maximum user message size is 2^14 bytes, which is a single * The maximum user message size is 2^14 (16384) bytes, which is a
DTLS record limit. single DTLS record limit.
* DTLS 1.0 has been deprecated for RFC 6083 requiring at least DTLS
1.2 [RFC8996]. This creates additional limitation as discussed in
Section 1.2.
This update that replaces RFC 6083 defines the following changes: This update that replaces RFC 6083 defines the following changes:
* Removes the limitations on user messages sizes by defining a * Removes the limitations on user messages sizes by defining a
secure fragmentation mechanism. secure fragmentation mechanism.
* Enable DTLS key-change without draining
* Mandates that more modern DTLS version are required (DTLS 1.2 or * Mandates that more modern DTLS version are required (DTLS 1.2 or
1.3) 1.3)
* Mandates use of modern HMAC algorithm (SHA-256) in the SCTP * Mandates support of modern HMAC algorithm (SHA-256) in the SCTP
authentication extension [RFC4895]. authentication extension [RFC4895].
* Recommends support of [RFC8260] to enable interleaving of large * Recommends support of [RFC8260] to enable interleaving of large
SCTP user messages to avoid scheduling issues. SCTP user messages to avoid scheduling issues.
* Applies stricter requirements on always using DTLS for all user * Applies stricter requirements on always using DTLS for all user
messages in the SCTP association. messages in the SCTP association.
* Requires that SCTP-AUTH is applied to all SCTP Chunks that can be * Requires that SCTP-AUTH is applied to all SCTP Chunks that can be
authenticated. authenticated.
* Requires support of partial delivery of user messages. * Requires support of partial delivery of user messages.
Mandating DTLS 1.2 or DTLS 1.3 instead to using DTLS 1.0 limits the 1.2. DTLS Version
lifetime of a DTLS connection and the data volume which can be
transferred over a DTLS connection. This is cause by:
* The number of renegotiations in DTLS 1.2 is limited to 65534 * The number of renegotiations in DTLS 1.2 is limited to 65534
compared to unlimited in DTLS 1.0. compared to unlimited in DTLS 1.0.
* The number of KeyUpdates in DTLS 1.3 is limited to 65532 and Using DTLS 1.2 instead of using DTLS 1.0 limits the lifetime of a
renegotiations are not supported. DTLS connection and the data volume which can be transferred over a
DTLS connection. This is caused by:
1.2. DTLS Version * The number of renegotiations in DTLS 1.2 is limited to 65534
compared to unlimited in DTLS 1.0.
DTLS/SCTP as defined by this document can use either DTLS 1.2 * While the AEAD limits in DTLS 1.3 does not formally apply to DTLS
[RFC6347] or DTLS 1.3 [I-D.ietf-tls-dtls13]. Some crucial difference 1.2 the mathematical limits apply equally well to DTLS 1.2.
between the DTLS versions make it necessary for a user of DTLS/SCTP
to make an informed choice of the DTLS version to use based on their
application's requirements. In general, DTLS 1.3 is to preferred
being a newer protocol that addresses known vulnerabilities and only
defines strong algorithms without known major weaknesses at the time
of publication.
However, some applications using DTLS/SCTP are of semi-permanent DTLS 1.3 comes with a large number of significant changes.
nature and use SCTP associations with lifetimes that are more than a
few hours, and where there is a significant cost of bringing down the * Renegotiations are not supported and instead partly replaced by
SCTP association in order to restart it. For such DTLS/SCTP usages KeyUpdates. The number of KeyUpdates is limited to 2^64.
that need either of:
* Strict AEAD significantly limits on how much many packets can be
sent before rekeying.
Many applications using DTLS/SCTP are of semi-permanent nature and
use SCTP associations with expected lifetimes of months or even
years, and where there is a significant cost of bringing down the
SCTP association in order to restart it. Such DTLS/SCTP usages that
need:
* Periodic re-authentication of both endpoints (not only the DTLS * Periodic re-authentication of both endpoints (not only the DTLS
client). client).
* Periodic rerunning of Diffie-Hellman key-exchange to provide * Periodic rerunning of Diffie-Hellman key-exchange to provide
Perfect Forward Secrecy (PFS) to reduce the impact any key-reveal. Perfect Forward Secrecy (PFS) to reduce the impact any key-reveal.
* Perform SCTP-AUTH re-keying. * Perform SCTP-AUTH re-keying.
At the time of publication DTLS 1.3 does not support any of these, At the time of publication DTLS 1.3 does not support any of these,
where DTLS 1.2 renegotiation functionality can provide this where DTLS 1.2 renegotiation functionality can provide this
functionality in the context of DTLS/SCTP. The application will have functionality in the context of DTLS/SCTP. To address these
to analyze its needs and requirements on the above and based on this requirements from semi-permanent applications, this document use
select the DTLS version to use. several overlapping DTLS connections with either DTLS 1.2 or 1.3.
Having uniform procedures reduces the impact when upgrading from 1.2
to 1.3 and avoids using the renegotiation mechanism which is disabled
by default in many DTLS implementations.
To address known vulnerabilities in DTLS 1.2 this document describes To address known vulnerabilities in DTLS 1.2 this document describes
and mandates implementation constraints on ciphers, protocol options and mandates implementation constraints on ciphers and protocol
and how to use the DTLS renegotiation mechanism. options. The DTLS 1.2 renegotiation mechanism is forbidden to be
used as it creates need for additional mechanism to handle race
conditions and interactions between using DTLS connections in
parallel.
In the rest of the document, unless the version of DTLS is In the rest of the document, unless the version of DTLS is
specifically called out the text applies to both versions of DTLS. specifically called out the text applies to both versions of DTLS.
1.3. Terminology 1.3. Terminology
This document uses the following terms: This document uses the following terms:
Association: An SCTP association. Association: An SCTP association.
Connection: An DTLS connection. It is uniquely identified by a
connection identifier.
Stream: A unidirectional stream of an SCTP association. It is Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by a stream identifier. uniquely identified by a stream identifier.
1.4. Abbreviations 1.4. Abbreviations
AEAD: Authenticated Encryption with Associated Data
DTLS: Datagram Transport Layer Security DTLS: Datagram Transport Layer Security
HMAC: Keyed-Hash Message Authentication Code
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
PFS: Perfect Forward Secrecy PFS: Perfect Forward Secrecy
PPID: Payload Protocol Identifier PPID: Payload Protocol Identifier
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
SCTP-AUTH: Authenticated Chunks for SCTP
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
TLS: Transport Layer Security TLS: Transport Layer Security
ULP: Upper Layer Protocol ULP: Upper Layer Protocol
2. Conventions 2. Conventions
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DTLS Considerations 3. DTLS Considerations
3.1. Version of DTLS 3.1. Version of DTLS
This document defines the usage of either DTLS 1.3 This document defines the usage of either DTLS 1.3
[I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of [I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of
DTLS MUST NOT be used (see [RFC8996]). It is expected that DTLS/SCTP DTLS MUST NOT be used (see [RFC8996]). DTLS 1.3 is RECOMMENDED for
as described in this document will work with future versions of DTLS. security and performance reasons. It is expected that DTLS/SCTP as
described in this document will work with future versions of DTLS.
3.2. Cipher Suites and Cryptographic Parameters 3.2. Cipher Suites and Cryptographic Parameters
For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be
used. For all versions of DTLS, cryptographic parameters giving used. For all versions of DTLS, cryptographic parameters giving
confidentiality and Perfect Forward Secrecy (PFS) MUST be used. confidentiality and Perfect Forward Secrecy (PFS) MUST be used.
3.3. Message Sizes 3.3. Message Sizes
DTLS/SCTP, automatically fragments and reassembles user messages. DTLS/SCTP, automatically fragments and reassembles user messages.
This specification defines how to fragment the user messages into This specification defines how to fragment the user messages into
DTLS records, where each DTLS 1.3 record allows a maximum of 2^14 DTLS records, where each DTLS record allows a maximum of 2^14
protected bytes. Each DTLS record adds some overhead, thus using protected bytes. Each DTLS record adds some overhead, thus using
records of maximum possible size are recommended to minimize the records of maximum possible size are recommended to minimize the
transmitted overhead. transmitted overhead. DTLS 1.3 has much less overhead than DTLS 1.2
per record.
The sequence of DTLS records is then fragmented into DATA or I-DATA The sequence of DTLS records is then fragmented into DATA or I-DATA
Chunks to fit the path MTU by SCTP. The largest possible user Chunks to fit the path MTU by SCTP. The largest possible user
messages using the mechanism defined in this specification is 2^64-1 messages using the mechanism defined in this specification is 2^64-1
bytes. bytes.
The security operations and reassembly process requires that the The security operations and reassembly process requires that the
protected user message, i.e., with DTLS record overhead, is buffered protected user message, i.e., with DTLS record overhead, is buffered
in the receiver. This buffer space will thus put a limit on the in the receiver. This buffer space will thus put a limit on the
largest size of plain text user message that can be transferred largest size of plain text user message that can be transferred
skipping to change at line 413 skipping to change at page 10, line 21
4. SCTP Considerations 4. SCTP Considerations
4.1. Mapping of DTLS Records 4.1. Mapping of DTLS Records
The SCTP implementation MUST support fragmentation of user messages The SCTP implementation MUST support fragmentation of user messages
using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks. using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks.
DTLS/SCTP works as a shim layer between the user message API and DTLS/SCTP works as a shim layer between the user message API and
SCTP. The fragmentation works similar as the DTLS fragmentation of SCTP. The fragmentation works similar as the DTLS fragmentation of
handshake messages. On the sender side a user message fragmented handshake messages. On the sender side a user message fragmented
into fragments m0, m1, m2, each no larger than 2^14 - 1 = 16383 into fragments m0, m1, m2, each no larger than 2^14 = 16384 bytes.
bytes.
m0 | m1 | m2 | ... = user_message m0 | m1 | m2 | ... = user_message
The resulting fragments are protected with DTLS and the records are The resulting fragments are protected with DTLS and the records are
concatenated concatenated
user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ... user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ...
The new user_message', i.e., the protected user message, is the input The new user_message', i.e., the protected user message, is the input
to SCTP. to SCTP.
On the receiving side DTLS is used to decrypt the individual records. On the receiving side DTLS is used to decrypt the individual records.
There are three failure cases an implementation needs to detect and There are three failure cases an implementation needs to detect and
then act on: then act on:
1. Failure in decryption and integrity verification process of any 1. Failure in decryption and integrity verification process of any
DTLS record. Due to SCTP-AUTH preventing delivery of injected or DTLS record. Due to SCTP-AUTH preventing delivery of injected or
corrupt fragments of the protected user message this should only corrupt fragments of the protected user message this should only
occur in case of implementation errors or internal hardware occur in case of implementation errors or internal hardware
failures. failures or the necessary security context has been prematurely
discarded.
2. In case the SCTP layer indicates an end to a user message, e.g. 2. In case the SCTP layer indicates an end to a user message, e.g.,
when receiving a MSG_EOR in a recvmsg() call when using the API when receiving a MSG_EOR in a recvmsg() call when using the API
described in [RFC6458], and the last buffered DTLS record length described in [RFC6458], and the last buffered DTLS record length
field does not match, i.e., the DTLS record is incomplete. field does not match, i.e., the DTLS record is incomplete.
3. Unable to perform the decryption processes due to lack of 3. Unable to perform the decryption processes due to lack of
resources, such as memory, and have to abandon the user message resources, such as memory, and have to abandon the user message
fragment. This specification is defined such that the needed fragment. This specification is defined such that the needed
resources for the DTLS/SCTP operations are bounded for a given resources for the DTLS/SCTP operations are bounded for a given
number of concurrent transmitted SCTP streams or unordered user number of concurrent transmitted SCTP streams or unordered user
messages. messages.
skipping to change at line 464 skipping to change at page 11, line 28
the DTLS connection and the SCTP association SHOULD be terminated. A the DTLS connection and the SCTP association SHOULD be terminated. A
valid exception to the termination of the SCTP association is if the valid exception to the termination of the SCTP association is if the
receiver is capable of notifying the ULP about the failure in receiver is capable of notifying the ULP about the failure in
delivery and the ULP is capable of recovering from this failure. delivery and the ULP is capable of recovering from this failure.
Note that if the SCTP extension for Partial Reliability (PR-SCTP) Note that if the SCTP extension for Partial Reliability (PR-SCTP)
[RFC3758] is used for a user message, user message may be partially [RFC3758] is used for a user message, user message may be partially
delivered or abandoned. These failures are not a reason for delivered or abandoned. These failures are not a reason for
terminating the DTLS connection and SCTP association. terminating the DTLS connection and SCTP association.
The DTLS Connection ID SHOULD NOT be negotiated (Section 9 of The DTLS Connection ID MUST be negotiated
[I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field MUST ([I-D.ietf-tls-dtls-connection-id] or Section 9 of
be included and a 16-bit sequence number SHOULD be used. [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field in the
record layer MUST be included. A 16-bit sequence number SHOULD be
used rather than 8-bit to minimize issues with DTLS record sequence
number wrapping.
The ULP may use multiple messages simultanous, and the progress and
delivery of these messages are progressing indepentely, thus the
recieving DTLS/SCTP implementation may not receive records in order
in case of packet loss. Assuming that the sender will send the DTLS
records in order the DTLS records where created (which may not be
certain in some implementations), then there is a risk that DTLS
sequence number have wrapped if the amount of data in flight is more
than the sequence number covers. Thus, for 8-bit sequence number
space with 16384 bytes records the receiver window only needs to be
256*16384 = 4,194,304 bytes for this risk to defintely exist. While
a 16-bit sequence number should not have any sequence number wraps
for receiver windows up to 1 Gbyte. The DTLS/SCTP may not be tightly
integrated and the DTLS records may not be requested to be sent in
strict sequence order, in these case additional guard ranges are
needed.
Also, if smaller DTLS records are used, this limit will be
correspondingly reduced. The DTLS/SCTP Sender needs to choose
sequence number length and DTLS Record size so that the product is
larger than the used receiver window, preferably twice as large.
Receiver implementations that are offering receiver windows larger
than the product 65536*16384 bytes MUST be capable of handling
sequence number wraps through trial decoding with a lower values in
the higher bits of the extended sequence number.
Section 4 of [I-D.ietf-tls-dtls-connection-id] states "If, however,
an implementation chooses to receive different lengths of CID, the
assigned CID values must be self-delineating since there is no other
mechanism available to determine what connection (and thus, what CID
length) is in use.". As this solution requires multiple connection
IDs, using a zero-length CID will be highly problematic as it could
result in that any DTLS records with a zero length CID ends up in
another DTLS connection context, and there fail the decryption and
integrity verification. And in that case to avoid losing the DTLS
record, it would have to be forwarded to the zero-length CID using
DTLS Connection and decryption and validation must be tried.
Resulting in higher resource utilization. Thus, it is RECOMMENDED to
not use the zero length CID values and instead use a single common
length for the CID values. A single byte should be sufficient, as
reuse of old CIDs is possible as long as the implementation ensure
they are not used in near time to the previous usage.
4.2. DTLS Connection Handling 4.2. DTLS Connection Handling
The DTLS connection MUST be established at the beginning of the SCTP A DTLS connection MUST be established at the beginning of the SCTP
association and be terminated when the SCTP association is association. All DTLS connections are terminated when the SCTP
terminated, (i.e., there's only one DTLS connection within one association is terminated. A DTLS connection MUST NOT span multiple
association). A DTLS connection MUST NOT span multiple SCTP SCTP associations.
associations.
As it is required to establish the DTLS connection at the beginning As it is required to establish the DTLS connection at the beginning
of the SCTP association, either of the peers should never send any of the SCTP association, either of the peers should never send any
SCTP user messages that are not protected by DTLS. So, the case that SCTP user messages that are not protected by DTLS. So, the case that
an endpoint receives data that is not either DTLS messages on Stream an endpoint receives data that is not either DTLS messages on Stream
0 or protected user messages in the form of a sequence of DTLS 0 or protected user messages in the form of a sequence of DTLS
Records on any stream is a protocol violation. The receiver MAY Records on any stream is a protocol violation. The receiver MAY
terminate the SCTP association due to this protocol violation. terminate the SCTP association due to this protocol violation.
Whenever a mutual authentication, updated security parameters, rerun
of Diffie-Hellman key-exchange , or SCTP-AUTH rekeying is needed, a
new DTLS connection is instead setup in parallel with the old
connection (i.e., there may be up to two simultaneous DTLS
connections within one association).
4.3. Payload Protocol Identifier Usage 4.3. Payload Protocol Identifier Usage
SCTP Payload Protocol Identifiers are assigned by IANA. Application SCTP Payload Protocol Identifiers are assigned by IANA. Application
protocols using DTLS over SCTP SHOULD register and use a separate protocols using DTLS over SCTP SHOULD register and use a separate
Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that
they registered for running directly over SCTP. they registered for running directly over SCTP.
Using the same PPID does not harm as long as the application can Using the same PPID does not harm as long as the application can
determine whether or not DTLS is used. However, for protocol determine whether or not DTLS is used. However, for protocol
analyzers, for example, it is much easier if a separate PPID is used. analyzers, for example, it is much easier if a separate PPID is used.
This means, in particular, that there is no specific PPID for DTLS. This means, in particular, that there is no specific PPID for DTLS.
4.4. Stream Usage 4.4. Stream Usage
All DTLS Handshake, Alert, or ChangeCipherSpec (DTLS 1.2 only) DTLS records with a content type different from "application_data"
messages MUST be transported on stream 0 with unlimited reliability (e.g., "handshake", "alert", ...) MUST be transported on stream 0
and with the ordered delivery feature. with unlimited reliability and with the ordered delivery feature.
DTLS messages of the record protocol, which carries the protected DTLS records of content type "application_data", which carries the
user messages, SHOULD use multiple streams other than stream 0; they protected user messages MAY be sent in SCTP messages on any stream,
MAY use stream 0. On stream 0 protected user messages as well as any including stream 0. On stream 0 the DTLS record containing the part
DTLS messages that aren't record protocol will be mixed, thus the of protected message, as well as any DTLS messages that aren't record
additional head of line blocking can occur. protocol will be mixed, thus the additional head of line blocking can
occur. Therefore, applications are RECOMMENDED to send its protected
user messages using multiple streams, and on other streams than
stream 0.
4.5. Chunk Handling 4.5. Chunk Handling
DATA chunks of SCTP MUST be sent in an authenticated way as described DATA chunks of SCTP MUST be sent in an authenticated way as described
in [RFC4895]. All other chunks that can be authenticated, i.e., all in SCTP-AUTH [RFC4895]. All other chunks that can be authenticated,
chunk types that can be listed in the Chunk List Parameter [RFC4895], i.e., all chunk types that can be listed in the Chunk List Parameter
MUST also be sent in an authenticated way. This makes sure that an [RFC4895], MUST also be sent in an authenticated way. This makes
attacker cannot modify the stream in which a message is sent or sure that an attacker cannot modify the stream in which a message is
affect the ordered/unordered delivery of the message. sent or affect the ordered/unordered delivery of the message.
If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST
also be sent in an authenticated way as described in [RFC4895]. This also be sent in an authenticated way as described in [RFC4895]. This
makes sure that it is not possible for an attacker to drop messages makes sure that it is not possible for an attacker to drop messages
and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
dropping. dropping.
I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be
supported to avoid some of the down sides that large user messages supported to avoid some of the down sides that large user messages
have on blocking transmission of later arriving high priority user have on blocking transmission of later arriving high priority user
skipping to change at line 540 skipping to change at page 14, line 21
4.6. SCTP-AUTH Hash Function 4.6. SCTP-AUTH Hash Function
When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be
supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT
be used when using DTLS/SCTP. [RFC4895] requires support and be used when using DTLS/SCTP. [RFC4895] requires support and
inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both
requirements the HMAC-ALGO parameter will include both SHA-256 and requirements the HMAC-ALGO parameter will include both SHA-256 and
SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference. SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference.
4.7. Renegotiation 4.7. Parallel DTLS connections
DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie- To enable SCTP-AUTH re-rekeying, periodic authentication of both
Hellman) of both DTLS and SCTP-AUTH as well as mutual endpoints, and force attackers to dynamic key extraction [RFC7624],
reauthentication inside an DTLS 1.2 connection. It is up to the DTLS/SCTP per this specification defines the usage of parallel DTLS
upper layer to use/allow it or not. Application writers should be connections over the same SCTP association. This solution ensures
aware that allowing renegotiations may result in changes of security that there are no limitations to the lifetime of the SCTP association
parameters. Renegotiation has been removed from DTLS 1.3 and partly due to DTLS, it also avoids dependency on version specific DTLS
replaced with post-handshake messages such as KeyUpdate. See mechanisms such as renegotiation in DTLS 1.2, which is disabled by
default in many DTLS implementations, or post-handshake messages in
DTLS 1.3, which does not allow mutual endpoint re-authentication or
re-keying of SCTP-AUTH. Parallel DTLS connections enable opening a
new DTLS connection performing a handshake, while the existing DTLS
connection is kept in place. On handshake completion switch to the
security context of the new DTLS connection and then ensure delivery
of all the SCTP chunks using the old DTLS connections security
context. When that has been achieved close the old DTLS connection
and discard the related security context.
As specified in Section 4.1 the usage of DTLS connection ID is
required to ensure that the receiver can correctly identify the DTLS
connection and its security context when performing its de-protection
operations. There is also only a single SCTP-AUTH key exported per
DTLS connection ensuring that there is clear mapping between the DTLS
connection ID and the SCTP-AUTH security context for each key-id.
Application writers should be aware that establishing a new DTLS
connections may result in changes of security parameters. See
Section 8 for security considerations regarding rekeying. Section 8 for security considerations regarding rekeying.
4.7.1. DTLS 1.2 Considerations A DTLS/SCTP Endpoint MUST NOT have more than two DTLS connections
open at the same time. Either of the endpoints MAY initiate a new
DTLS connection by performing a full DTLS handshake. As either
endpoint can initiate a DTLS handshake on either side at the same
time, either endpoint may receive a DTLS ClientHello when it has sent
its own ClientHello. In this case the ClientHello from the endpoint
that had the DTLS Client role in the establishment of the existing
DTLS connection shall be continued to be processed and the other
dropped.
Before sending during renegotiation a ClientHello message or When performing the DTLS handshake the endpoint MUST verify that the
ServerHello message, the DTLS endpoint MUST ensure that all DTLS peer identifies using the same identity as in the previous DTLS
messages using the previous epoch have been acknowledged by the SCTP connection.
peer in a non-revokable way.
Prior to processing a received ClientHello message or ServerHello When the DTLS handshake has been completed, a new SCTP-AUTH key will
message, all other received SCTP user messages that are buffered in be exported per Section 4.10 and the new DTLS connection MUST be used
the SCTP layer and can be delivered to the DTLS layer MUST be read for the DTLS protection operation of any future protected SCTP
and processed by DTLS. message. The endpoint is RECOMMENDED to use the security context of
the new DTLS connection for any DTLS protection operation occurring
after the completed handshake. The new SCTP-AUTH key SHALL be used
for any SCTP message being sent after the DTLS handshake has
completed. There is a possibility to use the new SCTP-AUTH key for
any SCTP packets part of an SCTP message that was initiated but not
yet fully transmitted prior to the completion of the new DTLS
handshake, however the API defined in [RFC6458] is not supporting
this.
4.7.2. DTLS 1.3 Considerations The SCTP endpoint will indicate to its peer when the previous DTLS
connection and its context are no longer needed for receiving any
more data from this endpoint. This is done by having DTLS to send a
DTLS close_notify alert. The endpoint MUST NOT send the close_notify
until the following two conditions are fulfilled:
1. All SCTP packets containing part of any DTLS record or message
protected using the security context of this DTLS connection have
been acknowledged in a non-renegable way.
2. All SCTP packets using the SCTP-AUTH key associated with the
security context of this DTLS connection have been acknowledged
in a non-renegable way.
There is a very basic way of determining the above conditions for an
implementation that enables using the new DTLS connection's security
context for all future DTLS records protected and enabling the
associated new SCTP-AUTH key at the same time and not use the old
context for any future protection operations. Mark the time when the
first SCTP chunk has been sent that is part of the first (partial)
SCTP message send call that uses the new security context. That SCTP
chunk and thus all previous chunks using the older security context
must have been delivered to the peer before the Endpoint Failure
Detection (See Section 8.1 of [RFC4960] would trigger and terminate
the SCTP association. Calculate the upper limit for this timeout
period, which is dependent on two configurable parameters. The
maximum endpoint failure timeout period is the product of the
'Association.Max.Retrans' and RTO.Max parameters. For the default
values per [RFC4960] that would be 10 attempts time with an RTO.Max =
60 s, i.e., 10 minutes.
For SCTP implementations exposing APIs like [RFC6458] where it is not
possible to change the SCTP-AUTH key for a partial SCTP message
initiated before the change of security context will be forced to
track the SCTP messages and determine when all using the old security
context has been transmitted. This maybe be impossible to do
completely reliable without tighter integration between the DTLS/SCTP
layer and the SCTP implementation. This type of implementations also
has an implicit limitation in how large SCTP messages it can support.
Each SCTP message needs have completed delivery and enabling closing
of the previous DTLS connection prior to the need to create yet
another DTLS connection. Thus, SCTP messages can't be larger than
that the transmission completes in less than the duration between the
rekeying or re-authentications needed for this SCTP association.
When the DTLS/SCTP implementation are more tightly integrated with
the SCTP stack or have a fuller API that enable the DTLS/SCTP
implementation to know when the SCPT messages have been delivered it
will be able to close down the old DTLS connection in a timelier
fashion, thus supporting more frequent rekeying etc. if needed.
The consequences of sending a DTLS close_notify alert in the old DTLS
connection prior to the receiver having received the data can result
in failure case 1 described in Section 4.1, which likely result in
SCTP association termination.
4.8. Renegotiation and KeyUpdate
DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie-
Hellman) of DTLS as well as mutual reauthentication inside an DTLS
1.2 connection. Renegotiation has been removed from DTLS 1.3 and
partly replaced with post-handshake messages such as KeyUpdate. The
parallel DTLS connection solution was specified due to lack of
necessary features with DTLS 1.3 considered needed for long lived
SCTP associations, such as rekeying (with ephemeral Diffie-Hellman)
as well as mutual reauthentication.
This specification do not allow usage of DTLS 1.2 renegotiation to
avoid race conditions and corner cases in the interaction between the
parallel DTLS connection mechanism and the keying of SCTP-AUTH. In
addtion renegotiation is also disabled in implementation, as well as
dealing with the epoch change reliable have similar or worse
applicaiton impact.
This specification also recommends against using DTLS 1.3 KeyUpdate
and instead rely on parallel DTLS connections. For DTLS 1.3 there
isn't feature parity. It also have the issue that a DTLS
implementation following the RFC may assume a too limited window for
SCTP where the previous epoch's security context is maintained and
thus changes to epoch handling (Section 4.9) are necessary. Thus,
unless the below specified more application impacting draining is
used there exist risk of losing data that the sender will have
assumed has been reliably delivered.
4.8.1. DTLS 1.2 Considerations
The endpoint MUST NOT use DTLS 1.2 renegotiation.
4.8.2. DTLS 1.3 Considerations
Before sending a KeyUpdate message, the DTLS endpoint MUST ensure Before sending a KeyUpdate message, the DTLS endpoint MUST ensure
that all DTLS messages have been acknowledged by the SCTP peer in a that all DTLS messages have been acknowledged by the SCTP peer in a
non-revokable way. After sending the KeyUpdate message, it stops non-revokable way. After sending the KeyUpdate message, it stops
sending DTLS messages until the corresponding Ack message has been sending DTLS messages until the corresponding Ack message has been
processed. processed.
Prior to processing a received KeyUpdate message, all other received Prior to processing a received KeyUpdate message, all other received
SCTP user messages that are buffered in the SCTP layer and can be SCTP user messages that are buffered in the SCTP layer and can be
delivered to the DTLS layer MUST be read and processed by DTLS. delivered to the DTLS layer MUST be read and processed by DTLS.
4.8. DTLS Epochs 4.9. DTLS Epochs
In general, DTLS implementations SHOULD discard records from earlier In general, DTLS implementations SHOULD discard records from earlier
epochs. However, in the context of a reliable communication this is epochs. However, in the context of a reliable communication this is
not appropriate. not appropriate.
4.8.1. DTLS 1.2 Considerations 4.9.1. DTLS 1.2 Considerations
The procedures of Section 4.1 of [RFC6347] MUST NOT be followed. Epochs will not be used as renegotiation is disallowed.
Instead, when currently using epoch n, for n > 1, DTLS packets from
epoch n - 1 and n MUST be processed.
4.8.2. DTLS 1.3 Considerations 4.9.2. DTLS 1.3 Considerations
The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are
irrelevant. When receiving DTLS packets using epoch n, no DTLS irrelevant. When receiving DTLS packets using epoch n, no DTLS
packets from earlier epochs are received. packets from earlier epochs are received.
4.9. Handling of Endpoint-Pair Shared Secrets 4.10. Handling of Endpoint-Pair Shared Secrets
SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In
SCTP associations where DTLS is used, DTLS is used to establish these SCTP associations where DTLS is used, DTLS is used to establish these
secrets. The endpoints MUST NOT use another mechanism for secrets. The endpoints MUST NOT use another mechanism for
establishing shared secrets for SCTP-AUTH. The endpoint-pair shared establishing shared secrets for SCTP-AUTH. The endpoint-pair shared
secret for Shared Key Identifier 0 is empty and MUST be used when secret for Shared Key Identifier 0 is empty and MUST be used when
establishing a DTLS connection. establishing the first DTLS connection.
4.9.1. DTLS 1.2 Considerations The initial DTLS connection will be used to establish a new shared
secret as specified per DTLS version below, and which MUST use shared
key identifier 1. After sending the DTLS Finished message, the
active SCTP-AUTH key MUST be switched to the new one. Once the
initial Finished message from the peer has been processed by DTLS,
the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed.
Whenever the master secret changes, a 64-byte shared secret is When a subsequent DTLS connection is setup, a new a 64-byte shared
derived from every master secret and provided as a new endpoint-pair secret is derived using the TLS-Exporter. The shared secret
shared secret by using the TLS-Exporter described in [RFC5705]. The identifiers form a sequence. If the previous shared secret used
64-byte shared secret MUST be provided to the SCTP stack as soon as Shared Key Identifier n, the new one MUST use Shared Key Identifier
the computation is possible. The exporter MUST use the label given n+1, unless n= 65535, in which case the new Shared Key Identifier is
in Section Section 7 and no context. The new Shared Key Identifier 1.
MUST be the old Shared Key Identifier incremented by 1.
After sending the DTLS Finished message, the active SCTP-AUTH key After sending the DTLS Finished message, the active SCTP-AUTH key
MUST be switched to the new one. MUST be switched to the new one. When the endpoint has both sent and
received a closeNotify on the old DTLS connection then the endpoint
SHALL remove shared secret(s) related to old DTLS connection.
Once the initial Finished message from the peer has been processed by 4.10.1. DTLS 1.2 Considerations
DTLS, the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed.
Once the Finished message using DTLS epoch n with n > 2 has been
processed by DTLS, the SCTP-AUTH key with Shared Key Identifier n - 2
MUST be removed.
4.9.2. DTLS 1.3 Considerations Whenever a new DTLS connection is established, a 64-byte
endpoint-pair shared secret is derived using the TLS-Exporter
described in {{RFC5705}}.
The 64-byte shared secret MUST be provided to the SCTP stack as soon
as the computation is possible. The exporter MUST use the label
given in Section 7 and no context.
4.10.2. DTLS 1.3 Considerations
When the exporter_secret can be computed, a 64-byte shared secret is When the exporter_secret can be computed, a 64-byte shared secret is
derived from it and provided as a new endpoint-pair shared secret by derived from it and provided as a new endpoint-pair shared secret by
using the TLS-Exporter described in [RFC8446]. The 64-byte shared using the TLS-Exporter described in [RFC8446].
secret MUST be provided to the SCTP stack as soon as the computation
is possible. The exporter MUST use the label given in
Section Section 7 and no context. This shared secret MUST use Shared
Key Identifier 1.
After sending the DTLS Finished message, the active SCTP-AUTH key
MUST be switched to use Shared Key Identifier 1.
Once the Finished message from the peer has been processed by DTLS, The 64-byte shared secret MUST be provided to the SCTP stack as soon
the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed. as the computation is possible. The exporter MUST use the label
given in Section Section 7 and no context.
4.10. Shutdown 4.11. Shutdown
To prevent DTLS from discarding DTLS user messages while it is To prevent DTLS from discarding DTLS user messages while it is
shutting down, a CloseNotify message MUST only be sent after all shutting down, a CloseNotify message MUST only be sent after all
outstanding SCTP user messages have been acknowledged by the SCTP outstanding SCTP user messages have been acknowledged by the SCTP
peer in a non-revokable way. peer in a non-revokable way.
Prior to processing a received CloseNotify, all other received SCTP Prior to processing a received CloseNotify, all other received SCTP
user messages that are buffered in the SCTP layer MUST be read and user messages that are buffered in the SCTP layer MUST be read and
processed by DTLS. processed by DTLS.
skipping to change at line 726 skipping to change at page 20, line 45
without all DTLS/SCTP Mandatory Options, it SHOULD reply with an SCTP without all DTLS/SCTP Mandatory Options, it SHOULD reply with an SCTP
ABORT. ABORT.
5.5. RFC 6083 Fallback 5.5. RFC 6083 Fallback
This section discusses how an endpoint supporting this specification This section discusses how an endpoint supporting this specification
can fallback to follow the DTLS/SCTP behavior in RFC6083. It is can fallback to follow the DTLS/SCTP behavior in RFC6083. It is
recommended to define a setting that represents the policy to allow recommended to define a setting that represents the policy to allow
fallback or not. However, the possibility to use fallback is based fallback or not. However, the possibility to use fallback is based
on the ULP can operate using user messages that are no longer than on the ULP can operate using user messages that are no longer than
16383 bytes and where the security issues can be mitigated or 16384 bytes and where the security issues can be mitigated or
considered acceptable. Fallback is NOT RECOMMEND to be enabled as it considered acceptable. Fallback is NOT RECOMMEND to be enabled as it
enables downgrade to weaker algorithms and versions of DTLS. enables downgrade attacks to weaker algorithms and versions of DTLS.
An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk
that does not contain the SCTP-Adaptation-Indication parameter with that does not contain the SCTP-Adaptation-Indication parameter with
the DTLS/SCTP adaptation layer codepoint, see Section 7.2, may in the DTLS/SCTP adaptation layer codepoint, see Section 7.2, may in
certain cases potentially perform a fallback to RFC 6083 behavior. certain cases potentially perform a fallback to RFC 6083 behavior.
However, the fallback attempt should only be performed if policy says However, the fallback attempt should only be performed if policy says
that is acceptable. that is acceptable.
If fallback is allowed, it is possible that the client will send If fallback is allowed, it is possible that the client will send
plain text user messages prior to DTLS handshake as it is allowed per plain text user messages prior to DTLS handshake as it is allowed per
skipping to change at line 763 skipping to change at page 21, line 38
received AUTH chunk. received AUTH chunk.
Furthermore, two new socket options for the level IPPROTO_SCTP and Furthermore, two new socket options for the level IPPROTO_SCTP and
the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are
defined as described below. The first socket option is used to query defined as described below. The first socket option is used to query
the HMAC algorithm used for sending AUTH chunks. The second enables the HMAC algorithm used for sending AUTH chunks. The second enables
the monitoring of HMAC algorithms used in received AUTH chunks via the monitoring of HMAC algorithms used in received AUTH chunks via
the SCTP_AUTHENTICATION_EVENT event. the SCTP_AUTHENTICATION_EVENT event.
Support for the SCTP_SEND_HMAC_IDENT and Support for the SCTP_SEND_HMAC_IDENT and
SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also needs to be added SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also need to be added
to the function sctp_opt_info(). to the function sctp_opt_info().
6.1. Socket Option to Get the HMAC Identifier being Sent 6.1. Socket Option to Get the HMAC Identifier being Sent
(SCTP_SEND_HMAC_IDENT) (SCTP_SEND_HMAC_IDENT)
During the SCTP association establishment a HMAC Identifier is During the SCTP association establishment a HMAC Identifier is
selected which is used by an SCTP endpoint when sending AUTH chunks. selected which is used by an SCTP endpoint when sending AUTH chunks.
An application can access the result of this selection by using this An application can access the result of this selection by using this
read-only socket option, which uses the level IPPROTO_SCTP and the read-only socket option, which uses the level IPPROTO_SCTP and the
name SCTP_SEND_HMAC_IDENT. name SCTP_SEND_HMAC_IDENT.
skipping to change at line 889 skipping to change at page 24, line 27
The security considerations given in [I-D.ietf-tls-dtls13], The security considerations given in [I-D.ietf-tls-dtls13],
[RFC4895], and [RFC4960] also apply to this document. [RFC4895], and [RFC4960] also apply to this document.
8.1. Cryptographic Considerations 8.1. Cryptographic Considerations
Over the years, there have been several serious attacks on earlier Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457] most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and summarizes the attacks that were known at the time of publishing and
BCP 195 [RFC7525] provides recommendations for improving the security BCP 195 [RFC7525] [RFC8996] provide recommendations for improving the
of deployed services that use TLS. security of deployed services that use TLS.
When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be
configured to disable options known to provide insufficient security. configured to disable options known to provide insufficient security.
HTTP/2 [RFC7540] gives good minimum requirements based on the attacks HTTP/2 [RFC7540] gives good minimum requirements based on the attacks
that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13] that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13]
only define strong algorithms without major weaknesses at the time of only define strong algorithms without major weaknesses at the time of
publication. Many of the TLS registries have a "Recommended" column. publication. Many of the TLS registries have a "Recommended" column.
Parameters not marked as "Y" are NOT RECOMMENDED to support. Parameters not marked as "Y" are NOT RECOMMENDED to support. DTLS
1.3 is preferred over DTLS 1.2 being a newer protocol that addresses
known vulnerabilities and only defines strong algorithms without
known major weaknesses at the time of publication.
DTLS 1.3 requires rekeying before algorithm specific AEAD limits have DTLS 1.3 requires rekeying before algorithm specific AEAD limits have
been reached. The AEAD limits equations are equally valid for DTLS been reached. The AEAD limits equations are equally valid for DTLS
1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the 1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the
DTLS 1.2 specification. DTLS 1.2 specification.
HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and
very good integrity properties. The SCTP-AUTH key can be used until very good integrity properties. The SCTP-AUTH key can be used longer
the DTLS handshake is re-run at which point a new SCTP-AUTH key is than the current algorithms in the TLS record layer. The SCTP-AUTH
derived using the TLS-Exporter. As discussed below DTLS 1.3 does not key is rekeyed when a new DTLS connection is set up at which point a
currently support renegotiation and lacks the capability of updating new SCTP-AUTH key is derived using the TLS-Exporter.
the SCTP-AUTH key.
DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST
(US), BSI (Germany), and ANSSI (France) recommends very frequent re- (US), BSI (Germany), and ANSSI (France) recommends very frequent re-
run of Diffie-Hellman to provide Perfect Forward Secrecy. ANSSI run of Diffie-Hellman to provide Perfect Forward Secrecy and force
writes "It is recommended to force the periodic renewal of the keys, attackers to dynamic key extraction [RFC7624]. ANSSI writes "It is
e.g., every hour and every 100 GB of data, in order to limit the recommended to force the periodic renewal of the keys, e.g., every
impact of a key compromise." [ANSSI-DAT-NT-003]. hour and every 100 GB of data, in order to limit the impact of a key
compromise." [ANSSI-DAT-NT-003].
For many DTLS/SCTP deployments the DTLS connections are expected to For many DTLS/SCTP deployments the SCTP association is expected to
have very long lifetimes of months or even years. For connections have a very long lifetime of months or even years. For associations
with such long lifetimes there is a need to frequently re- with such long lifetimes there is a need to frequently re-
authenticate both client and server. authenticate both client and server. TLS Certificate lifetimes
significantly shorter than a year are common which is shorter than
many expected DTLS/SCTP associations.
When using DTLS 1.2 [RFC6347], AEAD limits, frequent re- SCTP-AUTH re-rekeying, periodic authentication of both endpoints, and
authentication and frequent re-run of Diffie-Hellman can be achieved frequent re-run of Diffie-Hellman to force attackers to dynamic key
with frequent renegotiation, see TLS 1.2 [RFC5246]. When extraction is in DTLS/SCTP per this specification achieved by setting
renegotiation is used both clients and servers MUST use the up new DTLS connections over the same SCTP association.
renegotiation_info extension [RFC5746] and MUST follow the Implementations SHOULD set up new connections frequently to force
renegotiation guidelines in BCP 195 [RFC7525]. In particular, both attackers to dynamic key extraction. Implementations MUST set up new
clients and servers MUST NOT accept a change of identity during connections before any of the certificates expire. It is RECOMMENDED
renegotiation. that all negotiated and exchanged parameters are the same except for
the timestamps in the certificates. Clients and servers MUST NOT
accept a change of identity during the setup of a new connections,
but MAY accept negotiation of stronger algorithms and security
parameters, which might be motivated by new attacks.
In DTLS 1.3 renegotiation has been removed from DTLS 1.3 and partly When using DTLS 1.3 [I-D.ietf-tls-dtls13], AEAD limits and forward
replaced with Post-Handshake KeyUpdate. When using DTLS 1.3 secrecy can be achieved by sending post-handshake KeyUpdate messages,
[I-D.ietf-tls-dtls13], AEAD limits and frequent rekeying can be which triggers rekeying of DTLS. Such symmetric rekeying gives
achieved by sending frequent post-handshake KeyUpdate messages. significantly less protection against key leakage than re-running
Symmetric rekeying gives less protection against key leakage than re- Diffie-Hellman. After leakage of application_traffic_secret_N, a
running Diffie-Hellman. After leakage of passive attacker can passively eavesdrop on all future application
application_traffic_secret_N, a passive attacker can passively data sent on the connection including application data encrypted with
eavesdrop on all future application data sent on the connection
including application data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc. application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
The is no way to do post-handshake server authentication or Ephemeral Note that KeyUpdate does not update the exporter_secret.
Diffie-Hellman inside a DTLS 1.3 connection. Note that KeyUpdate
does not update the exporter_secret.
For upper layer protocols where frequent re-run of Diffie-Hellman, Allowing new connections can enable denial-of-service attacks. The
rekeying of SCTP-AUTH, and server reauthentication is required and endpoints SHOULD limit the frequency of new connections.
creating a new SCTP connection with DTLS 1.3 to replace the current
is not a viable option it is RECOMMENDED to use DTLS 1.2. When DTLS/SCTP is used with DTLS 1.2 [RFC6347], the TLS Session Hash
and Extended Master Secret Extension [RFC7627] MUST be used to
prevent unknown key-share attacks where an attacker establishes the
same key on several connections. DTLS 1.3 always prevents these
kinds of attacks. The use of SCTP-AUTH then cryptographically binds
new connections to the old connection. This together with mandatory
mutual authentication (on the DTLS layer) and a requirement to not
accept new identities mitigates MITM attacks that have plagued
renegotiation [TRISHAKE].
8.2. Downgrade Attacks 8.2. Downgrade Attacks
A peer supporting DTLS/SCTP according to this specification, DTLS/ A peer supporting DTLS/SCTP according to this specification, DTLS/
SCTP according to [RFC6083] and/or SCTP without DTLS may be SCTP according to [RFC6083] and/or SCTP without DTLS may be
vulnerable to downgrade attacks where on on-path attacker interferes vulnerable to downgrade attacks where on on-path attacker interferes
with the protocol setup to lower or disable security. If possible, with the protocol setup to lower or disable security. If possible,
it is RECOMMENDED that the peers have a policy only allowing DTLS/ it is RECOMMENDED that the peers have a policy only allowing DTLS/
SCTP according to this specification. SCTP according to this specification.
8.3. Authentication and Policy Decisions 8.3. Authentication and Policy Decisions
DTLS/SCTP MUST be mutually authenticated. It is RECOMMENDED that DTLS/SCTP MUST be mutually authenticated. Authentication is the
DTLS/SCTP is used with certificate-based authentication. All process of establishing the identity of a user or system and
security decisions MUST be based on the peer's authenticated verifying that the identity is valid. DTLS only provides proof of
possession of a key. DTLS/SCTP MUST perform identity authentication.
It is RECOMMENDED that DTLS/SCTP is used with certificate-based
authentication. When certificates are used the applicatication using
DTLS/SCTP is reposible for certificate policies, certificate chain
validation, and identity authentication (HTTPS does for example match
the hostname with a subjectAltName of type dNSName). The application
using DTLS/SCTP MUST define what the identity is and how it is
encoded and the client and server MUST use the same identity format.
Guidance on server certificate validation can be found in [RFC6125].
All security decisions MUST be based on the peer's authenticated
identity, not on its transport layer identity. identity, not on its transport layer identity.
It is possible to authenticate DTLS endpoints based on IP addresses It is possible to authenticate DTLS endpoints based on IP addresses
in certificates. SCTP associations can use multiple IP addresses per in certificates. SCTP associations can use multiple IP addresses per
SCTP endpoint. Therefore, it is possible that DTLS records will be SCTP endpoint. Therefore, it is possible that DTLS records will be
sent from a different source IP address or to a different destination sent from a different source IP address or to a different destination
IP address than that originally authenticated. This is not a problem IP address than that originally authenticated. This is not a problem
provided that no security decisions are made based on the source or provided that no security decisions are made based on the source or
destination IP addresses. destination IP addresses.
skipping to change at line 1010 skipping to change at page 27, line 34
Pervasive Monitoring is widespread surveillance of users. By Pervasive Monitoring is widespread surveillance of users. By
encrypting more information including user identities, DTLS 1.3 encrypting more information including user identities, DTLS 1.3
offers much better protection against pervasive monitoring. offers much better protection against pervasive monitoring.
Massive pervasive monitoring attacks relying on key exchange without Massive pervasive monitoring attacks relying on key exchange without
forward secrecy has been reported. By mandating perfect forward forward secrecy has been reported. By mandating perfect forward
secrecy, DTLS/SCTP effectively mitigate many forms of passive secrecy, DTLS/SCTP effectively mitigate many forms of passive
pervasive monitoring and limits the amount of compromised data due to pervasive monitoring and limits the amount of compromised data due to
key compromise. key compromise.
An important mitigation of pervasive monitoring is to force attackers
to do dynamic key exfiltration instead of static key exfiltration.
Dynamic key exfiltration increases the risk of discovery for the
attacker [RFC7624]. DTLS/SCTP per this specification encourages
implementations to frequently set up new DTLS connections over the
same SCTP association to force attackers to do dynamic key
exfiltration.
In addition to the privacy attacks discussed above, surveillance on a In addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wider geographical large scale may enable tracking of a user over a wider geographical
area and across different access networks. Using information from area and across different access networks. Using information from
DTLS/SCTP together with information gathered from other protocols DTLS/SCTP together with information gathered from other protocols
increase the risk of identifying individual users. increase the risk of identifying individual users.
9. Acknowledgments 9. Contributors
Michael Tuexen contributed as co-author to the intitial versions this
draft. Michael's contributions include:
* The use of the Adaptation Layer Indication.
* Socket API extension
* Many editorial improvements.
10. Acknowledgments
The authors of RFC 6083 which this document is based on are Michael The authors of RFC 6083 which this document is based on are Michael
Tuexen, Eric Rescorla, and Robin Seggelmann. Tuexen, Eric Rescorla, and Robin Seggelmann.
The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry
Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan
Lindskog, Daniel Mentz, and Sean Turner for their invaluable Lindskog, Daniel Mentz, and Sean Turner for their invaluable
comments. comments.
The authors of this document want to thank GitHub user vanrein for The authors of this document want to thank GitHub user vanrein for
their contribution. their contribution.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, Partial Reliability Extension", RFC 3758,
DOI 10.17487/RFC3758, May 2004, DOI 10.17487/RFC3758, May 2004,
skipping to change at line 1053 skipping to change at page 28, line 48
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission "Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
2007, <https://www.rfc-editor.org/info/rfc4895>. 2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>. March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<https://www.rfc-editor.org/info/rfc5746>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[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>.
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
skipping to change at line 1101 skipping to change at page 29, line 45
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>. <https://www.rfc-editor.org/info/rfc8996>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-43, 30 April 2021, <https://www.ietf.org/internet- dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>. drafts/draft-ietf-tls-dtls13-43.txt>.
10.2. Informative References [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-13, 22
June 2021, <https://www.ietf.org/archive/id/draft-ietf-
tls-dtls-connection-id-13.txt>.
11.2. Informative References
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, DOI 10.17487/RFC3436, December 2002, RFC 3436, DOI 10.17487/RFC3436, December 2002,
<https://www.rfc-editor.org/info/rfc3436>. <https://www.rfc-editor.org/info/rfc3436>.
[RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, [RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas,
"Security Considerations for Signaling Transport (SIGTRAN) "Security Considerations for Signaling Transport (SIGTRAN)
Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004, Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004,
<https://www.rfc-editor.org/info/rfc3788>. <https://www.rfc-editor.org/info/rfc3788>.
skipping to change at line 1125 skipping to change at page 30, line 27
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007, DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>. <https://www.rfc-editor.org/info/rfc5061>.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011, DOI 10.17487/RFC6083, January 2011,
<https://www.rfc-editor.org/info/rfc6083>. <https://www.rfc-editor.org/info/rfc6083>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011, DOI 10.17487/RFC6458, December 2011,
<https://www.rfc-editor.org/info/rfc6458>. <https://www.rfc-editor.org/info/rfc6458>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
skipping to change at line 1152 skipping to change at page 31, line 16
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <https://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[ANSSI-DAT-NT-003] [ANSSI-DAT-NT-003]
Agence nationale de la sécurité des systèmes Agence nationale de la sécurité des systèmes
d'information, ., "Recommendations for securing networks d'information, ., "Recommendations for securing networks
with IPsec", ANSSI Technical Report DAT-NT-003 , August with IPsec", ANSSI Technical Report DAT-NT-003 , August
2015, <<https://www.ssi.gouv.fr/uploads/2015/09/ 2015, <<https://www.ssi.gouv.fr/uploads/2015/09/
NT_IPsec_EN.pdf>>. NT_IPsec_EN.pdf>>.
[TRISHAKE] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "["Triple Handshakes and Cookie
Cutters", "Breaking and Fixing Authentication over TLS"]",
IEEE Symposium on Security & Privacy , April 2016,
<<https://hal.inria.fr/hal-01102259/file/triple-
handshakes-and-cookie-cutters-oakland14.pdf>>.
Appendix A. Motivation for Changes Appendix A. Motivation for Changes
This document proposes a number of changes to RFC 6083 that have This document proposes a number of changes to RFC 6083 that have
various different motivations: various different motivations:
Supporting Large User Messages: RFC 6083 allowed only user messages Supporting Large User Messages: RFC 6083 allowed only user messages
that could fit within a single DTLS record. 3GPP has run into this that could fit within a single DTLS record. 3GPP has run into this
limitation where they have at least four SCTP using protocols (F1, limitation where they have at least four SCTP using protocols (F1,
E1, Xn, NG-C) that can potentially generate messages over the size of E1, Xn, NG-C) that can potentially generate messages over the size of
16384 bytes. 16384 bytes.
New Versions: Almost 10 years has passed since RFC 6083 was written, New Versions: Almost 10 years has passed since RFC 6083 was written,
and significant evolution has happened in the area of DTLS and and significant evolution has happened in the area of DTLS and
security algorithms. Thus DTLS 1.3 is the newest version of DTLS and security algorithms. Thus DTLS 1.3 is the newest version of DTLS and
also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end
of usefulness. Thus, this document mandates usage of relevant of usefulness. Use of DTLS 1.3 with long lived associations require
versions and algorithms. parallel DTLS connections. Thus, this document mandates usage of
relevant versions and algorithms.
Clarifications: Some implementation experiences have been gained that Clarifications: Some implementation experiences have been gained that
motivates additional clarifications on the specification. motivates additional clarifications on the specification.
* Avoid unsecured messages prior to DTLS handshake have completed. * Avoid unsecured messages prior to DTLS handshake have completed.
* Make clear that all messages are encrypted after DTLS handshake. * Make clear that all messages are encrypted after DTLS handshake.
Authors' Addresses Authors' Addresses
skipping to change at line 1200 skipping to change at line 1470
John Preuß Mattsson John Preuß Mattsson
Ericsson Ericsson
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Claudio Porfiri Claudio Porfiri
Ericsson Ericsson
Email: claudio.porfiri@ericsson.com Email: claudio.porfiri@ericsson.com
Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
 End of changes. 84 change blocks. 
243 lines changed or deleted 513 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/