idnits 2.17.1 draft-ietf-tsvwg-dtls-over-sctp-bis-03.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6083, but the abstract doesn't seem to directly say this. It does mention RFC6083 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 780 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-TBD' is mentioned on line 1263, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG M. Westerlund 3 Internet-Draft J. Preuß Mattsson 4 Obsoletes: 6083 (if approved) C. Porfiri 5 Intended status: Standards Track Ericsson 6 Expires: 8 September 2022 7 March 2022 8 Datagram Transport Layer Security (DTLS) over Stream Control 9 Transmission Protocol (SCTP) 10 draft-ietf-tsvwg-dtls-over-sctp-bis-03 12 Abstract 14 This document describes the usage of the Datagram Transport Layer 15 Security (DTLS) protocol to protect user messages sent over the 16 Stream Control Transmission Protocol (SCTP). It is an improved 17 update of the existing rfc6083. 19 DTLS over SCTP provides mutual authentication, confidentiality, 20 integrity protection, and replay protection for applications that use 21 SCTP as their transport protocol and allows client/server 22 applications to communicate in a way that is designed to give 23 communications privacy and to prevent eavesdropping and detect 24 tampering or message forgery. 26 Applications using DTLS over SCTP can use almost all transport 27 features provided by SCTP and its extensions. This document intends 28 to obsolete RFC 6083 and removes the 16 kB limitation due to DTLS on 29 user message size by defining a secure user message fragmentation so 30 that multiple DTLS records can be used to protect a single user 31 message. It further updates the DTLS versions to use, as well as the 32 HMAC algorithms for SCTP-AUTH, and simplifies secure implementation 33 by some stricter requirements on the establishment procedures. 35 Discussion Venues 37 This note is to be removed before publishing as an RFC. 39 Source for this draft and an issue tracker can be found at 40 https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 8 September 2022. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1.1. Comparison with TLS for SCTP . . . . . . . . . . . . 5 78 1.1.2. Changes from RFC 6083 . . . . . . . . . . . . . . . . 5 79 1.2. DTLS Version . . . . . . . . . . . . . . . . . . . . . . 6 80 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 81 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 82 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 3.1. Version of DTLS . . . . . . . . . . . . . . . . . . . . . 8 85 3.2. Cipher Suites and Cryptographic Parameters . . . . . . . 8 86 3.3. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 8 87 3.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 9 88 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 10 89 3.6. Retransmission of Messages . . . . . . . . . . . . . . . 10 90 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 91 4.1. Mapping of DTLS Records . . . . . . . . . . . . . . . . . 10 92 4.2. DTLS Connection Handling . . . . . . . . . . . . . . . . 12 93 4.3. Payload Protocol Identifier Usage . . . . . . . . . . . . 13 94 4.4. Stream Usage . . . . . . . . . . . . . . . . . . . . . . 13 95 4.5. Chunk Handling . . . . . . . . . . . . . . . . . . . . . 14 96 4.6. SCTP-AUTH Hash Function . . . . . . . . . . . . . . . . . 15 97 4.7. Parallel DTLS connections . . . . . . . . . . . . . . . . 15 98 4.8. Renegotiation and KeyUpdate . . . . . . . . . . . . . . . 17 99 4.8.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 18 100 4.8.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 18 101 4.9. DTLS Epochs . . . . . . . . . . . . . . . . . . . . . . . 18 102 4.9.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 18 103 4.9.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 18 104 4.10. Handling of Endpoint-Pair Shared Secrets . . . . . . . . 19 105 4.10.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . 19 106 4.10.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . 19 107 4.11. Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 20 108 5. DTLS over SCTP Service . . . . . . . . . . . . . . . . . . . 21 109 5.1. Adaptation Layer Indication in INIT/INIT-ACK . . . . . . 21 110 5.2. DTLS over SCTP Initialization . . . . . . . . . . . . . . 21 111 5.3. Client Use Case . . . . . . . . . . . . . . . . . . . . . 22 112 5.4. Server Use Case . . . . . . . . . . . . . . . . . . . . . 22 113 5.5. RFC 6083 Fallback . . . . . . . . . . . . . . . . . . . . 23 114 5.5.1. Client Fallback . . . . . . . . . . . . . . . . . . . 23 115 5.5.2. Server Fallback . . . . . . . . . . . . . . . . . . . 24 116 6. SCTP API Consideration . . . . . . . . . . . . . . . . . . . 24 117 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 25 118 7.1. Socket Option to Get the HMAC Identifier being Sent 119 (SCTP_SEND_HMAC_IDENT) . . . . . . . . . . . . . . . . . 25 120 7.2. Exposing the HMAC Identifiers being Received . . . . . . 26 121 7.3. Socket Option to Expose HMAC Identifier Usage 122 (SCTP_EXPOSE_HMAC_IDENT_CHANGES) . . . . . . . . . . . . 26 123 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 124 8.1. TLS Exporter Label . . . . . . . . . . . . . . . . . . . 27 125 8.2. SCTP Adaptation Layer Indication Code Point . . . . . . . 27 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 127 9.1. Cryptographic Considerations . . . . . . . . . . . . . . 28 128 9.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 30 129 9.3. Targeting DTLS Messages . . . . . . . . . . . . . . . . . 30 130 9.4. Authentication and Policy Decisions . . . . . . . . . . . 30 131 9.5. Resumption and Tickets . . . . . . . . . . . . . . . . . 31 132 9.6. Privacy Considerations . . . . . . . . . . . . . . . . . 31 133 9.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 31 134 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 135 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 136 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 137 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 138 12.2. Informative References . . . . . . . . . . . . . . . . . 34 139 Appendix A. Motivation for Changes . . . . . . . . . . . . . . . 36 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 142 1. Introduction 144 1.1. Overview 146 This document describes the usage of the Datagram Transport Layer 147 Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS 148 1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission 149 Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks 150 for SCTP (SCTP-AUTH) [RFC4895]. 152 This specification provides mutual authentication of endpoints, 153 confidentiality, integrity protection, and replay protection of user 154 messages for applications that use SCTP as their transport protocol. 155 Thus, it allows client/server applications to communicate in a way 156 that is designed to give communications privacy and to prevent 157 eavesdropping and detect tampering or message forgery. DTLS/SCTP 158 uses DTLS for mutual authentication, key exchange with forward 159 secrecy for SCTP-AUTH, and confidentiality of user messages. DTLS/ 160 SCTP use SCTP and SCTP-AUTH for integrity protection and replay 161 protection of user messages. 163 Applications using DTLS over SCTP can use almost all transport 164 features provided by SCTP and its extensions. DTLS/SCTP supports: 166 * preservation of message boundaries. 168 * a large number of unidirectional and bidirectional streams. 170 * ordered and unordered delivery of SCTP user messages. 172 * the partial reliability extension as defined in [RFC3758]. 174 * the dynamic address reconfiguration extension as defined in 175 [RFC5061]. 177 * User messages of any size. 179 The method described in this document requires that the SCTP 180 implementation supports the optional feature of fragmentation of SCTP 181 user messages as defined in [RFC4960]. The implementation is 182 required to have an SCTP API (for example the one described in 183 [RFC6458]) that supports partial user message delivery and also 184 recommended that I-DATA chunks as defined in [RFC8260] is used to 185 efficiently implement and support larger user messages. 187 To simplify implementation and reduce the risk for security holes, 188 limitations have been defined such that STARTTLS as specified in 189 [RFC3788] is no longer supported. 191 1.1.1. Comparison with TLS for SCTP 193 TLS, from which DTLS was derived, is designed to run on top of a 194 byte-stream-oriented transport protocol providing a reliable, in- 195 sequence delivery. TLS over SCTP as described in [RFC3436] has some 196 serious limitations: 198 * It does not support the unordered delivery of SCTP user messages. 200 * It does not support partial reliability as defined in [RFC3758]. 202 * It only supports the usage of the same number of streams in both 203 directions. 205 * It uses a TLS connection for every bidirectional stream, which 206 requires a substantial amount of resources and message exchanges 207 if a large number of streams is used. 209 1.1.2. Changes from RFC 6083 211 The DTLS over SCTP solution defined in RFC 6083 had the following 212 limitations: 214 * The maximum user message size is 2^14 (16384) bytes, which is a 215 single DTLS record limit. 217 * DTLS 1.0 has been deprecated for RFC 6083 requiring at least DTLS 218 1.2 [RFC8996]. This creates additional limitation as discussed in 219 Section 1.2. 221 * DTLS messages that don't contain protected user message data where 222 limited to only be sent on Stream 0 and requiring that stream to 223 be in-order delivery which could potentially impact applicaitons. 225 This specification defines the following changes compared with RFC 226 6083: 228 * Removes the limitations on user messages sizes by defining a 229 secure fragmentation mechanism. It is optional to support message 230 sizes over 2^64-1 bytes. 232 * Enable DTLS key-change without requiring draining all inflight 233 user message from SCTP. 235 * Mandates that more modern DTLS version are used (DTLS 1.2 or 1.3) 237 * Mandates support of modern HMAC algorithm (SHA-256) in the SCTP 238 authentication extension [RFC4895]. 240 * Recommends support of [RFC8260] to enable interleaving of large 241 SCTP user messages to avoid scheduling issues. 243 * Applies stricter requirements on always using DTLS for all user 244 messages in the SCTP association. 246 * Requires that SCTP-AUTH is applied to all SCTP Chunks that can be 247 authenticated. 249 * Requires support of partial delivery of user messages. 251 1.2. DTLS Version 253 Using DTLS 1.2 instead of using DTLS 1.0 limits the lifetime of a 254 DTLS connection and the data volume which can be transferred over a 255 DTLS connection. This is caused by: 257 * The number of renegotiations in DTLS 1.2 is limited to 65534 258 compared to unlimited in DTLS 1.0. 260 * While the AEAD limits in DTLS 1.3 does not formally apply to DTLS 261 1.2 the mathematical limits apply equally well to DTLS 1.2. 263 DTLS 1.3 comes with a large number of significant changes. 265 * Renegotiations are not supported and instead partly replaced by 266 KeyUpdates. The number of KeyUpdates is limited to 2^64. 268 * Strict AEAD significantly limits on how much many packets can be 269 sent before rekeying. 271 Many applications using DTLS/SCTP are of semi-permanent nature and 272 use SCTP associations with expected lifetimes of months or even 273 years, and where there is a significant cost of bringing down the 274 SCTP association in order to restart it. Such DTLS/SCTP usages that 275 need: 277 * Periodic re-authentication and transfer of revocation information 278 of both endpoints (not only the DTLS client). 280 * Periodic rerunning of Diffie-Hellman key-exchange to provide 281 forward secrecy and mitigate static key exfiltration attacks. 283 * Perform SCTP-AUTH rekeying. 285 At the time of publication DTLS 1.3 does not support any of these, 286 where DTLS 1.2 renegotiation functionality can provide this 287 functionality in the context of DTLS/SCTP. To address these 288 requirements from semi-permanent applications, this document use 289 several overlapping DTLS connections with either DTLS 1.2 or 1.3. 290 Having uniform procedures reduces the impact when upgrading from 1.2 291 to 1.3 and avoids using the renegotiation mechanism which is disabled 292 by default in many DTLS implementations. 294 To address known vulnerabilities in DTLS 1.2 this document describes 295 and mandates implementation constraints on ciphers and protocol 296 options. The DTLS 1.2 renegotiation mechanism is forbidden to be 297 used as it creates need for additional mechanism to handle race 298 conditions and interactions between using DTLS connections in 299 parallel. 301 In the rest of the document, unless the version of DTLS is 302 specifically called out the text applies to both versions of DTLS. 304 1.3. Terminology 306 This document uses the following terms: 308 Association: An SCTP association. 310 Connection: An DTLS connection. It is uniquely identified by a 311 connection identifier. 313 Stream: A unidirectional stream of an SCTP association. It is 314 uniquely identified by a stream identifier. 316 1.4. Abbreviations 318 AEAD: Authenticated Encryption with Associated Data 320 DTLS: Datagram Transport Layer Security 322 HMAC: Keyed-Hash Message Authentication Code 324 MTU: Maximum Transmission Unit 326 PPID: Payload Protocol Identifier 328 SCTP: Stream Control Transmission Protocol 330 SCTP-AUTH: Authenticated Chunks for SCTP 332 TCP: Transmission Control Protocol 334 TLS: Transport Layer Security 335 ULP: Upper Layer Protocol 337 2. Conventions 339 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 340 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 341 "OPTIONAL" in this document are to be interpreted as described in BCP 342 14 [RFC2119] [RFC8174] when, and only when, they appear in all 343 capitals, as shown here. 345 3. DTLS Considerations 347 3.1. Version of DTLS 349 This document defines the usage of either DTLS 1.3 350 [I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of 351 DTLS MUST NOT be used (see [RFC8996]). DTLS 1.3 is RECOMMENDED for 352 security and performance reasons. It is expected that DTLS/SCTP as 353 described in this document will work with future versions of DTLS. 355 3.2. Cipher Suites and Cryptographic Parameters 357 For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be 358 used. For all versions of DTLS, cryptographic parameters giving 359 confidentiality and forward secrecy MUST be used. 361 3.3. Message Sizes 363 DTLS/SCTP, automatically fragments and reassembles user messages. 364 This specification defines how to fragment the user messages into 365 DTLS records, where each DTLS record allows a maximum of 2^14 366 protected bytes. Each DTLS record adds some overhead, thus using 367 records of maximum possible size are recommended to minimize the 368 transmitted overhead. DTLS 1.3 has much less overhead than DTLS 1.2 369 per record. 371 The sequence of DTLS records is then fragmented into DATA or I-DATA 372 Chunks to fit the path MTU by SCTP. These changes ensures that DTLS/ 373 SCTP has the same capability as SCTP to support user messages of any 374 size. However, to simplify implementations it is OPTIONAL to support 375 user messages larger than 2^64-1 bytes. This is to allow 376 implementation to assume that 64-bit length fields and offset 377 pointers will be sufficient. 379 Another implementation dependent exception to the support of any user 380 message size is the SCTP-API defined in [RFC6458]. That API does not 381 allow changing the SCTP-AUTH key used to send a particular user 382 message. Thus, the user message size must be limited such that 383 completion of the user message can occur within a short time frame 384 from the establishment of the new DTLS connection (Section 4.7). 386 The security operations and reassembly process requires that the 387 protected user message, i.e., with DTLS record overhead, is buffered 388 in the receiver. This buffer space will thus put a limit on the 389 largest size of plain text user message that can be transferred 390 securely. However, by mandating the use of the partial delivery of 391 user messages from SCTP and assuming that no two messages received on 392 the same stream are interleaved (as it is the case when using the API 393 defined in [RFC6458]) the required buffering prior to DTLS processing 394 can be limited to a single DTLS record per used incoming stream. 395 This enables the DTLS/SCTP implementation to provide the Upper Layer 396 Protocol (ULP) with each DTLS record's content when it has been 397 decrypted and its integrity been verified enabling partial user 398 message delivery to the ULP. Implementations can trade-off buffer 399 memory requirements in the DTLS layer with transport overhead by 400 using smaller DTLS records. 402 The DTLS/SCTP implementation is expected to behave very similar to 403 just SCTP when it comes to handling of user messages and dealing with 404 large user messages and their reassembly and processing. Making it 405 the ULP responsible for handling any resource contention related to 406 large user messages. 408 3.4. Replay Protection 410 SCTP-AUTH [RFC4895] does not have explicit replay protection. 411 However, the combination of SCTP-AUTH's protection of DATA or I-DATA 412 chunks and SCTP user message handling will prevent third party 413 attempts to inject or replay SCTP packets resulting in impact on the 414 received protected user message. In fact, this document's solution 415 is dependent on SCTP-AUTH and SCTP to prevent reordering, 416 duplication, and removal of the DTLS records within each protected 417 user message. This includes detection of changes to what DTLS 418 records start and end the SCTP user message, and removal of DTLS 419 records before an increment to the epoch. Without SCTP-AUTH, these 420 would all have required explicit handling. 422 DTLS optionally supports record replay detection. Such replay 423 detection could result in the DTLS layer dropping valid messages 424 received outside of the DTLS replay window. As DTLS/SCTP provides 425 replay protection even without DTLS replay protection, the replay 426 detection of DTLS MUST NOT be used. 428 3.5. Path MTU Discovery 430 DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides Path 431 MTU discovery and fragmentation/reassembly for user messages, and 432 specified in Section 3.3, DTLS can send maximum sized DTLS Records. 434 3.6. Retransmission of Messages 436 SCTP provides a reliable and in-sequence transport service for DTLS 437 messages that require it. See Section 4.4. Therefore, DTLS 438 procedures for retransmissions MUST NOT be used. 440 4. SCTP Considerations 442 4.1. Mapping of DTLS Records 444 The SCTP implementation MUST support fragmentation of user messages 445 using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks. 447 DTLS/SCTP works as a shim layer between the user message API and 448 SCTP. On the sender side a user message is split into fragments m0, 449 m1, m2, each no larger than 2^14 = 16384 bytes. 451 m0 | m1 | m2 | ... = user_message 453 The resulting fragments are protected with DTLS and the records are 454 concatenated 456 user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ... 458 The new user_message', i.e., the protected user message, is the input 459 to SCTP. 461 On the receiving side, the length field in each DTLS record can be 462 used to determine the boundaries between DTLS records. DTLS can 463 decrypt individual records or a concatenated sequence of records. 464 The last DTLS record can be found by subtracting the length of 465 individual records from the length of user_message'. Whether to 466 decrypt individual records, sequences of records, or the whole 467 user_message' is left to the implementation. The output from the 468 DTLS decryption(s) is the fragments m0, m1, m2 ... The user_message 469 is reassembled from decrypted DTLS records as user_message = m0 | 470 m1 | m2 ... There are three failure cases an implementation needs to 471 detect and then act on: 473 1. Failure in decryption and integrity verification process of any 474 DTLS record. Due to SCTP-AUTH preventing delivery of injected or 475 corrupt fragments of the protected user message this should only 476 occur in case of implementation errors or internal hardware 477 failures or the necessary security context has been prematurely 478 discarded. 480 2. In case the SCTP layer indicates an end to a user message, e.g., 481 when receiving a MSG_EOR in a recvmsg() call when using the API 482 described in [RFC6458], and the last buffered DTLS record length 483 field does not match, i.e., the DTLS record is incomplete. 485 3. Unable to perform the decryption processes due to lack of 486 resources, such as memory, and have to abandon the user message 487 fragment. This specification is defined such that the needed 488 resources for the DTLS/SCTP operations are bounded for a given 489 number of concurrent transmitted SCTP streams or unordered user 490 messages. 492 The above failure cases all result in the receiver failing to 493 recreate the full user message. This is a failure of the transport 494 service that is not possible to recover from in the DTLS/SCTP layer 495 and the sender could believe the complete message have been 496 delivered. This error MUST NOT be ignored, as SCTP lacks any 497 facility to declare a failure on a specific stream or user message, 498 the DTLS connection and the SCTP association SHOULD be terminated. A 499 valid exception to the termination of the SCTP association is if the 500 receiver is capable of notifying the ULP about the failure in 501 delivery and the ULP is capable of recovering from this failure. 503 Note that if the SCTP extension for Partial Reliability (PR-SCTP) 504 [RFC3758] is used for a user message, user message may be partially 505 delivered or abandoned. These failures are not a reason for 506 terminating the DTLS connection and SCTP association. 508 The DTLS Connection ID MUST be negotiated 509 ([I-D.ietf-tls-dtls-connection-id] or Section 9 of 510 [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field in the 511 record layer MUST be included in all records. A 16-bit sequence 512 number SHOULD be used rather than 8-bit to minimize issues with DTLS 513 record sequence number wrapping. 515 The ULP may use multiple messages simultanous, and the progress and 516 delivery of these messages are progressing indepentely, thus the 517 recieving DTLS/SCTP implementation may not receive records in order 518 in case of packet loss. Assuming that the sender will send the DTLS 519 records in order the DTLS records where created (which may not be 520 certain in some implementations), then there is a risk that DTLS 521 sequence number have wrapped if the amount of data in flight is more 522 than the sequence number covers. Thus, for 8-bit sequence number 523 space with 16384 bytes records the receiver window only needs to be 524 256*16384 = 4,194,304 bytes for this risk to defintely exist. While 525 a 16-bit sequence number should not have any sequence number wraps 526 for receiver windows up to 1 Gbyte. The DTLS/SCTP may not be tightly 527 integrated and the DTLS records may not be requested to be sent in 528 strict sequence order, in these case additional guard ranges are 529 needed. 531 Also, if smaller DTLS records are used, this limit will be 532 correspondingly reduced. The DTLS/SCTP Sender needs to choose 533 sequence number length and DTLS Record size so that the product is 534 larger than the used receiver window, preferably twice as large. 535 Receiver implementations that are offering receiver windows larger 536 than the product 65536*16384 bytes MUST be capable of handling 537 sequence number wraps through trial decoding with a lower values in 538 the higher bits of the extended sequence number. 540 Section 4 of [I-D.ietf-tls-dtls-connection-id] states "If, however, 541 an implementation chooses to receive different lengths of CID, the 542 assigned CID values must be self-delineating since there is no other 543 mechanism available to determine what connection (and thus, what CID 544 length) is in use.". As this solution requires multiple connection 545 IDs, using a zero-length CID will be highly problematic as it could 546 result in that any DTLS records with a zero length CID ends up in 547 another DTLS connection context, and there fail the decryption and 548 integrity verification. And in that case to avoid losing the DTLS 549 record, it would have to be forwarded to the zero-length CID using 550 DTLS Connection and decryption and validation must be tried. 551 Resulting in higher resource utilization. Thus, it is RECOMMENDED to 552 not use the zero length CID values and instead use a single common 553 length for the CID values. A single byte should be sufficient, as 554 reuse of old CIDs is possible as long as the implementation ensure 555 they are not used in near time to the previous usage. 557 4.2. DTLS Connection Handling 559 DTLS/SCTP is negotiated on SCTP level as an adaptation layer 560 Section 5. After a succesful negotiation of the DTLS/SCTP during 561 SCTP association establishment, a DTLS connection MUST be established 562 prior to transmission of any ULP user messages. All DTLS connections 563 are terminated when the SCTP association is terminated. A DTLS 564 connection MUST NOT span multiple SCTP associations. 566 As it is required to establish the DTLS connection at the beginning 567 of the SCTP association, either of the peers should never send any 568 SCTP user messages that are not protected by DTLS. So, the case that 569 an endpoint receives data that is not either DTLS messages or 570 protected user messages in the form of a sequence of DTLS Records on 571 any stream is a protocol violation. The receiver MAY terminate the 572 SCTP association due to this protocol violation. Implementations 573 that does not have a DTLS endpoint immediately ready on SCTP 574 handshake completion will have to ensure correct caching of the 575 messages until the DTLS endpoint is ready. 577 Whenever a mutual authentication, updated security parameters, rerun 578 of Diffie-Hellman key-exchange , or SCTP-AUTH rekeying is needed, a 579 new DTLS connection is instead setup in parallel with the old 580 connection (i.e., there may be up to two simultaneous DTLS 581 connections within one association). 583 4.3. Payload Protocol Identifier Usage 585 SCTP Payload Protocol Identifiers are assigned by IANA. Application 586 protocols using DTLS over SCTP SHOULD register and use a separate 587 Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that 588 they registered for running directly over SCTP. 590 Using the same PPID does no harm as DTLS/SCTP requires all user 591 mesages being DTLS protected and knows that DTLS is used. However, 592 for protocol analyzers, for example, it is much easier if a separate 593 PPID is used and avoids different behavior from [RFC6083]. This 594 means, in particular, that there is no specific PPID for DTLS. 596 Messages that are exchanged between DTLS/SCTP peers not containing 597 ULP user messages shall use PPID=0 according to section 3.3.1 of 598 [RFC4960] as no application identifier can be specified by the upper 599 layer for this payload data. 601 4.4. Stream Usage 603 DTLS 1.3 protects the actual content type of the DTLS record and have 604 therefore omitted the non-protected content type field. Thus, it is 605 not possible to determine which content type the DTLS record has on 606 SCTP level. For DTLS 1.2 ULP user messages will be carried in DTLS 607 records with content type "application_data". 609 DTLS Records carrying protected user message fragments MUST be sent 610 in the by ULP indicated SCTP stream and user message. The ULP has no 611 limitations in using SCTP facilities for stream and user messages. 612 DTLS records of other types MAY be sent on any stream. It MAY also 613 be sent in its own SCTP user message as well as interleaved with 614 other DTLS records carrying protected user messages. Thus, it is 615 allowed to insert between protected user message fragments DTLS 616 records of other types as the DTLS receiver will process these and 617 not result in any user message data being inserted into the ULP's 618 user message. However, DTLS messages of other types than protected 619 user message MUST be sent reliable, so the DTLS record can only be 620 interleaved in case the ULP user message is sent as reliable. 622 DTLS is capable of handling reordering of the DTLS records. However, 623 depending on stream properties and which user message DTLS records of 624 other types are sent in may impact in which order and how quickly 625 they are possible to process. Using a stream with in-order delivery 626 will ensure that the DTLS Records are delivered in the order they are 627 sent in user messages. Thus, ensuring that if there are DTLS records 628 that need to be delivered in particular order it can be ensured. 629 Alternatively, if it is desired that a DTLS record is delvired as 630 early as possible avoiding in-order streams with queued messages and 631 considering stream priorities can result in faster delviery. 633 A simple solution avoiding any protocol issue are to send all DTLS 634 messages that are not protected user message fragments is to pick a 635 stream not used by the ULP, send the DTLS messages in their own user 636 messages with in order delivery. That mimics the RFC 6083 behavior 637 without impacting the ULP. 639 4.5. Chunk Handling 641 DATA chunks of SCTP MUST be sent in an authenticated way as described 642 in SCTP-AUTH [RFC4895]. All other chunks that can be authenticated, 643 i.e., all chunk types that can be listed in the Chunk List Parameter 644 [RFC4895], MUST also be sent in an authenticated way. This makes 645 sure that an attacker cannot modify the stream in which a message is 646 sent or affect the ordered/unordered delivery of the message. 648 If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST 649 also be sent in an authenticated way as described in [RFC4895]. This 650 makes sure that it is not possible for an attacker to drop messages 651 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this 652 dropping. 654 I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be 655 supported to avoid some of the down sides that large user messages 656 have on blocking transmission of later arriving high priority user 657 messages. However, the support is not mandated and negotiated 658 independently from DTLS/SCTP. If I-DATA chunks are used, then they 659 MUST be sent in an authenticated way as described in [RFC4895]. 661 4.6. SCTP-AUTH Hash Function 663 When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be 664 supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT 665 be used when using DTLS/SCTP. [RFC4895] requires support and 666 inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both 667 requirements the HMAC-ALGO parameter will include both SHA-256 and 668 SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference. 670 4.7. Parallel DTLS connections 672 To enable SCTP-AUTH rekeying, periodic authentication of both 673 endpoints, and force attackers to dynamic key extraction [RFC7624], 674 DTLS/SCTP per this specification defines the usage of parallel DTLS 675 connections over the same SCTP association. This solution ensures 676 that there are no limitations to the lifetime of the SCTP association 677 due to DTLS, it also avoids dependency on version specific DTLS 678 mechanisms such as renegotiation in DTLS 1.2, which is disabled by 679 default in many DTLS implementations, or post-handshake messages in 680 DTLS 1.3, which does not allow periodic mutual endpoint re- 681 authentication or re-keying of SCTP-AUTH. Parallel DTLS connections 682 enable opening a new DTLS connection performing a handshake, while 683 the existing DTLS connection is kept in place. In DTLS 1.3 the 684 handshake MAY be a full handshake or a resumption handshake and 685 resumption can be done while the original connection is still open. 686 In DTLS 1.2 the handshake MUST be a full handshake. On handshake 687 completion switch to the security context of the new DTLS connection 688 and then ensure delivery of all the SCTP chunks using the old DTLS 689 connections security context. When that has been achieved close the 690 old DTLS connection and discard the related security context. 692 As specified in Section 4.1 the usage of DTLS connection ID is 693 required to ensure that the receiver can correctly identify the DTLS 694 connection and its security context when performing its de-protection 695 operations. There is also only a single SCTP-AUTH key exported per 696 DTLS connection ensuring that there is clear mapping between the DTLS 697 connection ID and the SCTP-AUTH security context for each key-id. 699 Application writers should be aware that establishing a new DTLS 700 connections may result in changes of security parameters. See 701 Section 9 for security considerations regarding rekeying. 703 A DTLS/SCTP Endpoint MUST NOT have more than two DTLS connections 704 open at the same time. Either of the endpoints MAY initiate a new 705 DTLS connection by performing a full DTLS handshake. As either 706 endpoint can initiate a DTLS handshake on either side at the same 707 time, either endpoint may receive a DTLS ClientHello when it has sent 708 its own ClientHello. In this case the ClientHello from the endpoint 709 that had the DTLS Client role in the establishment of the existing 710 DTLS connection shall be continued to be processed and the other 711 dropped. 713 When performing the DTLS handshake the endpoint MUST verify that the 714 peer identifies using the same identity as in the previous DTLS 715 connection. 717 When the DTLS handshake has been completed, a new SCTP-AUTH key will 718 be exported per Section 4.10 and the new DTLS connection MUST be used 719 for the DTLS protection operation of any future protected ULP user 720 message. The endpoint is RECOMMENDED to use the security context of 721 the new DTLS connection for any DTLS protection operation occurring 722 after the completed handshake. The new SCTP-AUTH key SHALL be used 723 for any SCTP user message being sent after the DTLS handshake has 724 completed. There is a possibility to use the new SCTP-AUTH key for 725 any SCTP packets part of an SCTP user message that was initiated but 726 not yet fully transmitted prior to the completion of the new DTLS 727 handshake, however the API defined in [RFC6458] is not supporting 728 switching the SCTP-AUTH key on the sender side. Any SCTP-AUTH 729 receiver implementation is expected to be able to select key on SCTP 730 packet basis. 732 The DTLS/SCTP endpoint will indicate to its peer when the previous 733 DTLS connection and its context are no longer needed for receiving 734 any more data from this endpoint. This is done by having DTLS to 735 send a DTLS close_notify alert. The endpoint MUST NOT send the 736 close_notify until the following two conditions are fulfilled: 738 1. All SCTP packets containing part of any DTLS record or message 739 protected using the security context of this DTLS connection have 740 been acknowledged in a non-renegable way. 742 2. All SCTP packets using the SCTP-AUTH key associated with the 743 security context of this DTLS connection have been acknowledged 744 in a non-renegable way. 746 Note: For DTLS 1.2 receiving Close_notify will close the DTLS 747 connection for further writes and requires the immediate generation 748 of a Close_notify. Thus, this forces the DTLS/SCTP to protect any 749 buffered data on DTLS/SCTP layer not yet protected to use the new 750 DTLS connection. In addition the DTLS/SCTP layer will have to buffer 751 the close_notify generated by the shuting down DTLS connection and 752 also not discard the SCTP-AUTH key until it has fulfilled the 753 delivery of the data protected by the closing DTLS connection 754 security context. 756 SCTP implementations exposing APIs like [RFC6458] fulfilling these 757 conditions requires draining the SCTP association of all outstanding 758 data after having completed all the user messages using the previous 759 SCTP-AUTH key identifier. Relying on the SCTP_SENDER_DRY_EVENT to 760 know when delivery has been accomplished. A richer API could also be 761 used that allows user message level tracking of delivery, see 762 Section 6 for API considerations. 764 For SCTP implementations exposing APIs like [RFC6458] where it is not 765 possible to change the SCTP-AUTH key for a partial SCTP message 766 initiated before the change of security context will be forced to 767 track the SCTP messages and determine when all using the old security 768 context has been transmitted. This maybe be impossible to do 769 completely reliable without tighter integration between the DTLS/SCTP 770 layer and the SCTP implementation. This type of implementations also 771 has an implicit limitation in how large SCTP messages it can support. 772 Each SCTP message needs have completed delivery and enabling closing 773 of the previous DTLS connection prior to the need to create yet 774 another DTLS connection. Thus, SCTP messages can't be larger than 775 that the transmission completes in less than the duration between the 776 rekeying or re-authentications needed for this SCTP association. 778 The consequences of sending a DTLS close_notify alert in the old DTLS 779 connection prior to the receiver having received the data can result 780 in failure case 1 described in Section 4.1, which likely result in 781 SCTP association termination. 783 4.8. Renegotiation and KeyUpdate 785 DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie- 786 Hellman) of DTLS as well as mutual reauthentication and transfer of 787 revocation information inside an DTLS 1.2 connection. Renegotiation 788 has been removed from DTLS 1.3 and partly replaced with post- 789 handshake messages such as KeyUpdate. The parallel DTLS connection 790 solution was specified due to lack of necessary features with DTLS 791 1.3 considered needed for long lived SCTP associations, such as 792 rekeying (with ephemeral Diffie-Hellman) as well as mutual 793 reauthentication. 795 This specification do not allow usage of DTLS 1.2 renegotiation to 796 avoid race conditions and corner cases in the interaction between the 797 parallel DTLS connection mechanism and the keying of SCTP-AUTH. In 798 addtion renegotiation is also disabled in implementation, as well as 799 dealing with the epoch change reliable have similar or worse 800 applicaiton impact. 802 This specification also recommends against using DTLS 1.3 KeyUpdate 803 and instead rely on parallel DTLS connections. For DTLS 1.3 there 804 isn't feature parity. It also have the issue that a DTLS 805 implementation following the RFC may assume a too limited window for 806 SCTP where the previous epoch's security context is maintained and 807 thus changes to epoch handling (Section 4.9) are necessary. Thus, 808 unless the below specified more application impacting draining is 809 used there exist risk of losing data that the sender will have 810 assumed has been reliably delivered. 812 4.8.1. DTLS 1.2 Considerations 814 The endpoint MUST NOT use DTLS 1.2 renegotiation. 816 4.8.2. DTLS 1.3 Considerations 818 Before sending a KeyUpdate message, the DTLS endpoint MUST ensure 819 that all DTLS messages have been acknowledged by the SCTP peer in a 820 non-revokable way. After sending the KeyUpdate message, it stops 821 sending DTLS messages until the corresponding Ack message has been 822 processed. 824 Prior to processing a received KeyUpdate message, all other received 825 SCTP user messages that are buffered in the SCTP layer and can be 826 delivered to the DTLS layer MUST be read and processed by DTLS. 828 4.9. DTLS Epochs 830 In general, DTLS implementations SHOULD discard records from earlier 831 epochs. However, in the context of a reliable communication this is 832 not appropriate. 834 4.9.1. DTLS 1.2 Considerations 836 Epochs will not be used as renegotiation is disallowed. 838 4.9.2. DTLS 1.3 Considerations 840 The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are 841 irrelevant. When receiving DTLS packets using epoch n, no DTLS 842 packets from earlier epochs are received. 844 4.10. Handling of Endpoint-Pair Shared Secrets 846 SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In 847 SCTP associations where DTLS is used, DTLS is used to establish these 848 secrets. The endpoints MUST NOT use another mechanism for 849 establishing shared secrets for SCTP-AUTH. The endpoint-pair shared 850 secret for Shared Key Identifier 0 is empty and MUST be used when 851 establishing the first DTLS connection. 853 The initial DTLS connection will be used to establish a new shared 854 secret as specified per DTLS version below, and which MUST use shared 855 key identifier 1. After sending the DTLS Finished message for the 856 initial DTLS connection, the active SCTP-AUTH key MUST be switched 857 from key identifier 0 to key identifier 1. Once the initial Finished 858 message from the peer has been processed by DTLS, the SCTP-AUTH key 859 with Shared Key Identifier 0 MUST be removed. 861 When a subsequent DTLS connection is setup, a new a 64-byte shared 862 secret is derived using the TLS-Exporter. The shared secret 863 identifiers form a sequence. If the previous shared secret used 864 Shared Key Identifier n, the new one MUST use Shared Key Identifier 865 n+1, unless n= 65535, in which case the new Shared Key Identifier is 866 1. 868 After sending the DTLS Finished message, the active SCTP-AUTH key 869 MUST be switched to the new one. When the endpoint has both sent and 870 received a closeNotify on the old DTLS connection then the endpoint 871 SHALL remove shared secret(s) related to old DTLS connection. 873 4.10.1. DTLS 1.2 Considerations 875 Whenever a new DTLS connection is established, a 64-byte 876 endpoint-pair shared secret is derived using the TLS-Exporter 877 described in {{RFC5705}}. 879 The 64-byte shared secret MUST be provided to the SCTP stack as soon 880 as the computation is possible. The exporter MUST use the label 881 given in Section 8 and no context. 883 4.10.2. DTLS 1.3 Considerations 885 When the exporter_secret can be computed, a 64-byte shared secret is 886 derived from it and provided as a new endpoint-pair shared secret by 887 using the TLS-Exporter described in [RFC8446]. 889 The 64-byte shared secret MUST be provided to the SCTP stack as soon 890 as the computation is possible. The exporter MUST use the label 891 given in Section Section 8 and no context. 893 4.11. Shutdown 895 To prevent DTLS from discarding DTLS user messages while it is 896 shutting down, the below procedure has been defined. Its goal is to 897 avoid the need for APIs requiring per user message data level 898 acknowledgments and utilizes existing SCTP protocol behavior to 899 ensure delivery of the protected user messages data. 901 Note, this proceudre currenlty only works for DTLS 1.3. For DTLS 1.2 902 users the remote endpoint will be closed for sending more data with 903 the reception of the close_notify in step 5, and step 6 will not be 904 possible and that data will be lost. 906 The interaction between peers and protocol stacks shall be as 907 follows: 909 1. Local instance of ULP asks for terminating the DTLS/SCTP 910 Association. 912 2. Local DTLS/SCTP acknowledge the request, from this time on no 913 new data from local instance of ULP will be accepted. In case a 914 DTLS connection handshake is ongoing this needs to be aborted 915 conclusively at this step to ensure that the necessary DTLS 916 message exchange happens prior to draining any outstanding data 917 in the SCTP association from this endpoint. 919 3. Local DTLS/SCTP finishes any protection operation on buffered 920 user messages and ensures that all protected user message data 921 has been successfully transferred to the remote ULP. 923 4. Local DTLS/SCTP sends DTLS Close_notify to remote instance of 924 DTLS/SCTP on each and all DTLS connections, keys and session 925 state are kept for processing packets received later on. 927 5. When receiving Close_notify on the last open DTLS connection, 928 remote DTLS/SCTP instance informs its ULP that remote shutdown 929 has been initiated. When two parallel DTLS connections are in 930 place it is important to await Close_notify alert on both to not 931 misstake a rekeying. No more ULP user message data to be sent 932 to peer can be accepted by DTLS/SCTP. In case this endpoint has 933 initiated and DTLS connection handshake this MUST be aborted as 934 the peer is unable to respond. 936 6. Remote DTLS/SCTP finishes any protection operation on buffered 937 user messages and ensures that all protected user message data 938 has been successfully transferred to the remote ULP. 940 7. Remote DTLS/SCTP sends Close_notify to Local DTLS/SCTP entity 941 for each and all DTLS connections. 943 8. When receiving Close_notify on the last open DTLS connection, 944 local DTLS/SCTP instance initiates the SCTP shutdown procedure 945 (section 9.2 of [RFC4960]). 947 9. Remote DTLS/SCTP replied to the SCTP shutdown procedure (section 948 9.2 of [RFC4960]). 950 10. Upon receiving the information that SCTP has closed the 951 Association, independently the local and remote DTLS/SCTP 952 entities destroy the DTLS connection. 954 The verification in step 3 and 6 that all user data message has been 955 successfully delivered to the remote ULP can be provided by the SCTP 956 stack that implements [RFC6458] by means of SCTP_SENDER_DRY event 957 (section 6.1.9 of [RFC6458]). 959 A successful SCTP shutdown will indicate successful delivery of all 960 data. However, in cases of communication failures and extensive 961 packet loss the SCTP shutdown procedure can time out and result in 962 SCTP association termination where its unknown if all data has been 963 delivered. The DTLS/SCTP should indicate to ULP successful 964 completion or failure to shutdown gracefully. 966 5. DTLS over SCTP Service 968 The adoption of DTLS over SCTP according to the current specification 969 is meant to add to SCTP the option for transferring encrypted data. 970 When DTLS over SCTP is used, all data being transferred MUST be 971 protected by chunk authentication and DTLS encrypted. Chunks that 972 need to be received in an authenticated way will be specified in the 973 CHUNK list parameter according to [RFC4895]. Error handling for 974 authenticated chunks is according to [RFC4895]. 976 5.1. Adaptation Layer Indication in INIT/INIT-ACK 978 At the initialization of the association, a sender of the INIT or 979 INIT ACK chunk that intends to use DTLS/SCTP as specified in this 980 specification MUST include an Adaptation Layer Indication Parameter 981 with the IANA assigned value TBD (Section 8.2) to inform its peer 982 that it is able to support DTLS over SCTP per this specification. 984 5.2. DTLS over SCTP Initialization 986 Initialization of DTLS/SCTP requires all the following options to be 987 part of the INIT/INIT-ACK handshake: 989 RANDOM: defined in [RFC4895] 991 CHUNKS: list of permitted chunks, defined in [RFC4895] 993 HMAC-ALGO: defined in [RFC4895] 995 ADAPTATION-LAYER-INDICATION: defined in [RFC5061] 997 When all the above options are present and having acceptable 998 parameters, the Association will start with support of DTLS/SCTP. 999 The set of options indicated are the DTLS/SCTP Mandatory Options. No 1000 data transfer is permitted before DTLS handshake is complete. Chunk 1001 bundling is permitted according to [RFC4960]. The DTLS handshake 1002 will enable authentication of both the peers. 1004 The extension described in this document is given by the following 1005 message exchange. 1007 --- INIT[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] ---> 1008 <- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] - 1009 ------------------------ COOKIE-ECHO ------------------------> 1010 <------------------------ COOKIE-ACK ------------------------- 1011 ---------------- AUTH; DATA[DTLS Handshake] -----------------> 1012 ... 1013 ... 1014 <--------------- AUTH; DATA[DTLS Handshake] ------------------ 1016 5.3. Client Use Case 1018 When a client initiates an SCTP Association with DTLS protection, 1019 i.e., the SCTP INIT containing DTSL/SCTP Mandatory Options, it can 1020 receive an INIT-ACK also containing DTLS/SCTP Mandatory Options, in 1021 that case the Association will proceed as specified in the previous 1022 Section 5.2 section. If the peer replies with an INIT-ACK not 1023 containing all DTLS/SCTP Mandatory Options, the client SHOULD reply 1024 with an SCTP ABORT. 1026 5.4. Server Use Case 1028 If a SCTP Server supports DTLS/SCTP, i.e., per this specification, 1029 when receiving an INIT chunk with all DTLS/SCTP Mandatory Options it 1030 will reply with an INIT-ACK also containing all the DTLS/SCTP 1031 Mandatory Options, following the sequence for DTLS initialization 1032 Section 5.2 and the related traffic case. If a SCTP Server that 1033 supports DTLS and configured to use it, receives an INIT chunk 1034 without all DTLS/SCTP Mandatory Options, it SHOULD reply with an SCTP 1035 ABORT. 1037 5.5. RFC 6083 Fallback 1039 This section discusses how an endpoint supporting this specification 1040 can fallback to follow the DTLS/SCTP behavior in RFC6083. It is 1041 recommended to define a setting that represents the policy to allow 1042 fallback or not. However, the possibility to use fallback is based 1043 on the ULP can operate using user messages that are no longer than 1044 16384 bytes and where the security issues can be mitigated or 1045 considered acceptable. Fallback is NOT RECOMMEND to be enabled as it 1046 enables downgrade attacks to weaker algorithms and versions of DTLS. 1048 An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk 1049 that does not contain the SCTP-Adaptation-Indication parameter with 1050 the DTLS/SCTP adaptation layer codepoint, see Section 8.2, may in 1051 certain cases potentially perform a fallback to RFC 6083 behavior. 1052 However, the fallback attempt should only be performed if policy says 1053 that is acceptable. 1055 If fallback is allowed, it is possible that the client will send 1056 plain text user messages prior to DTLS handshake as it is allowed per 1057 RFC 6083. So that needs to be part of the consideration for a policy 1058 allowing fallback. 1060 5.5.1. Client Fallback 1062 A DTLS/SCTP client supporting this specficiation encountering an 1063 server not compatible with this specficiation MAY attempt RFC 6083 1064 fallback per this procedure. 1066 1. Fallback procedure, if enabled, is initiated when receiving an 1067 SCTP INIT-ACK that does not contain the DTLS/SCTP Adaptation 1068 Layer indication. If fallback is not enabled the SCTP handshake 1069 is aborted. 1071 2. The client checks that the SCTP INIT-ACK contained the necessary 1072 chunks and parameters to establish SCTP-AUTH per RFC 6083 with 1073 this endpoint. If not all necessary parameters or support 1074 algorithms don't match the client MUST abort the handshake. 1075 Otherwise it complets the SCTP handshake. 1077 3. Client performs DTLS connection handshake per RFC 6083 over 1078 established SCTP association. If succesfull authenticating the 1079 targeted server the client has succesfull fallen back to use RFC 1080 6083. If not terminate the SCTP association. 1082 5.5.2. Server Fallback 1084 A DTLS/SCTP Server that supports both this specification and RFC 6083 1085 and where fallback has been enabled for the ULP can follow this 1086 procedure. 1088 1. When receving an SCTP INIT message without the DTLS/SCTP 1089 adapation layer indicataion fallback procedure is initiated. 1091 2. Verify that the SCTP INIT contains SCTP-AUTH parameters required 1092 by RFC 6083 and compatible with this server. If that is not the 1093 case abort the SCTP handshake. 1095 3. Send an SCTP INIT ACK with the required SCTP-AUTH chunks and 1096 parameters to the client. 1098 4. Complete the SCTP Handshake. Await DTLS handshake per RFC 6083. 1099 Plain text SCTP messages MAY be received. 1101 5. Upon succesful completion of DTLS handshake succesfull fallback 1102 to RFC 6083 have been accomplished. 1104 6. SCTP API Consideration 1106 DTLS/SCTP needs certain functionality on the API that the SCTP 1107 implementation provide to the ULP to function optimally. A DTLS/SCTP 1108 implementation will need to provide its own API to the ULP, while 1109 itself using the SCTP API. This discussion is focused on the needed 1110 functionality on the SCTP API. 1112 The following functionality is needed: 1114 * Controlling SCPT-AUTH negotiation so that SHA-256 algorithm is 1115 inlcuded, and determine that SHA-1 is not selected when the 1116 association is established. 1118 * Determine when all SCTP packets that uses an SCTP-auth key or 1119 contains DTLS records associated to a particular DTLS connection 1120 has been acknowledge in a non-renegable manor. 1122 * Determine when all SCTP packets have been acknowledge in a non- 1123 renegable manor. 1125 * Negotiate the adaptation layer indication that indicates DTLS/SCTP 1126 and determine if it was agreed or not. 1128 * Partial user messages transmission and reception. 1130 7. Socket API Considerations 1132 This section describes how the socket API defined in [RFC6458] is 1133 extended to provide a way for the application to observe the HMAC 1134 algorithms used for sending and receiving of AUTH chunks. 1136 Please note that this section is informational only. 1138 A socket API implementation based on [RFC6458] is, by means of the 1139 existing SCTP_AUTHENTICATION_EVENT event, extended to provide the 1140 event notification whenever a new HMAC algorithm is used in a 1141 received AUTH chunk. 1143 Furthermore, two new socket options for the level IPPROTO_SCTP and 1144 the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are 1145 defined as described below. The first socket option is used to query 1146 the HMAC algorithm used for sending AUTH chunks. The second enables 1147 the monitoring of HMAC algorithms used in received AUTH chunks via 1148 the SCTP_AUTHENTICATION_EVENT event. 1150 Support for the SCTP_SEND_HMAC_IDENT and 1151 SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also need to be added 1152 to the function sctp_opt_info(). 1154 7.1. Socket Option to Get the HMAC Identifier being Sent 1155 (SCTP_SEND_HMAC_IDENT) 1157 During the SCTP association establishment a HMAC Identifier is 1158 selected which is used by an SCTP endpoint when sending AUTH chunks. 1159 An application can access the result of this selection by using this 1160 read-only socket option, which uses the level IPPROTO_SCTP and the 1161 name SCTP_SEND_HMAC_IDENT. 1163 The following structure is used to access HMAC Identifier used for 1164 sending AUTH chunks: 1166 struct sctp_assoc_value { 1167 sctp_assoc_t assoc_id; 1168 uint32_t assoc_value; 1169 }; 1171 assoc_id: This parameter is ignored for one-to-one style sockets. 1172 For one-to-many style sockets, the application fills in an 1173 association identifier. It is an error to use 1174 SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id. 1176 assoc_value: This parameter contains the HMAC Identifier used for 1177 sending AUTH chunks. 1179 7.2. Exposing the HMAC Identifiers being Received 1181 Section 6.1.8 of [RFC6458] defines the SCTP_AUTHENTICATION_EVENT 1182 event, which uses the following structure: 1184 struct sctp_authkey_event { 1185 uint16_t auth_type; 1186 uint16_t auth_flags; 1187 uint32_t auth_length; 1188 uint16_t auth_keynumber; 1189 uint32_t auth_indication; 1190 sctp_assoc_t auth_assoc_id; 1191 }; 1193 This document updates this structure to 1195 struct sctp_authkey_event { 1196 uint16_t auth_type; 1197 uint16_t auth_flags; 1198 uint32_t auth_length; 1199 uint16_t auth_identifier; /* formerly auth_keynumber */ 1200 uint32_t auth_indication; 1201 sctp_assoc_t auth_assoc_id; 1202 }; 1204 by renaming auth_keynumber to auth_identifier. auth_identifier just 1205 replaces auth_keynumber in the context of [RFC6458]. In addition to 1206 that, the SCTP_AUTHENTICATION_EVENT event is extended to also 1207 indicate when a new HMAC Identifier is received and such reporting is 1208 explicitly enabled as described in Section 7.3. In this case 1209 auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is 1210 reported in auth_identifier. 1212 7.3. Socket Option to Expose HMAC Identifier Usage 1213 (SCTP_EXPOSE_HMAC_IDENT_CHANGES) 1215 This options allows the application to enable and disable the 1216 reception of SCTP_AUTHENTICATION_EVENT events when a new HMAC 1217 Identifiers has been received in an AUTH chunk (see Section 7.2). 1218 This read/write socket option uses the level IPPROTO_SCTP and the 1219 name SCTP_EXPOSE_HMAC_IDENT_CHANGES. It is needed to provide 1220 backwards compatibility and the default is that these events are not 1221 reported. 1223 The following structure is used to enable or disable the reporting of 1224 newly received HMAC Identifiers in AUTH chunks: 1226 struct sctp_assoc_value { 1227 sctp_assoc_t assoc_id; 1228 uint32_t assoc_value; 1229 }; 1231 assoc_id: This parameter is ignored for one-to-one style sockets. 1232 For one-to-many style sockets, the application may fill in an 1233 association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC. 1235 assoc_value: Newly received HMAC Identifiers are reported if, and 1236 only if, this parameter is non-zero. 1238 8. IANA Considerations 1240 8.1. TLS Exporter Label 1242 RFC 6083 defined a TLS Exporter Label registry as described in 1243 [RFC5705]. IANA is requested to update the reference for the label 1244 "EXPORTER_DTLS_OVER_SCTP" to this specification. 1246 8.2. SCTP Adaptation Layer Indication Code Point 1248 [RFC5061] defined a IANA registry for Adaptation Code Points to be 1249 used in the Adaptation Layer Indication parameter. The registry was 1250 at time of writing located: https://www.iana.org/assignments/sctp- 1251 parameters/sctp-parameters.xhtml#sctp-parameters-27 IANA is requested 1252 to assign one Adaptation Code Point for DTLS/SCTP per the below 1253 proposed entry in Table 1. 1255 +============================+=============+===========+ 1256 | Code Point (32-bit number) | Description | Reference | 1257 +============================+=============+===========+ 1258 | 0x00000002 | DTLS/SCTP | [RFC-TBD] | 1259 +----------------------------+-------------+-----------+ 1261 Table 1: Adaptation Code Point 1263 RFC-Editor Note: Please replace [RFC-TBD] with the RFC number given 1264 to this specification. 1266 9. Security Considerations 1268 The security considerations given in [I-D.ietf-tls-dtls13], 1269 [RFC4895], and [RFC4960] also apply to this document. 1271 9.1. Cryptographic Considerations 1273 Over the years, there have been several serious attacks on earlier 1274 versions of Transport Layer Security (TLS), including attacks on its 1275 most commonly used ciphers and modes of operation. [RFC7457] 1276 summarizes the attacks that were known at the time of publishing and 1277 BCP 195 [RFC7525] [RFC8996] provide recommendations for improving the 1278 security of deployed services that use TLS. 1280 When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be 1281 configured to disable options known to provide insufficient security. 1282 HTTP/2 [RFC7540] gives good minimum requirements based on the attacks 1283 that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13] 1284 only define strong algorithms without major weaknesses at the time of 1285 publication. Many of the TLS registries have a "Recommended" column. 1286 Parameters not marked as "Y" are NOT RECOMMENDED to support. DTLS 1287 1.3 is preferred over DTLS 1.2 being a newer protocol that addresses 1288 known vulnerabilities and only defines strong algorithms without 1289 known major weaknesses at the time of publication. 1291 DTLS 1.3 requires rekeying before algorithm specific AEAD limits have 1292 been reached. The AEAD limits equations are equally valid for DTLS 1293 1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the 1294 DTLS 1.2 specification. 1296 HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and 1297 very good integrity properties. The SCTP-AUTH key can be used longer 1298 than the current algorithms in the TLS record layer. The SCTP-AUTH 1299 key is rekeyed when a new DTLS connection is set up at which point a 1300 new SCTP-AUTH key is derived using the TLS-Exporter. 1302 (D)TLS 1.3 [RFC8446] discusses forward secrecy from EC(DHE), 1303 KeyUpdate, and tickets/resumption. Forward secrecy limits the effect 1304 of key leakage in one direction (compromise of a key at time T2 does 1305 not compromise some key at time T1 where T1 < T2). Protection in the 1306 other direction (compromise at time T1 does not compromise keys at 1307 time T2) can be achieved by rerunning EC(DHE). If a long-term 1308 authentication key has been compromised, a full handshake with 1309 EC(DHE) gives protection against passive attackers. If the 1310 resumption_master_secret has been compromised, a resumption handshake 1311 with EC(DHE) gives protection against passive attackers and a full 1312 handshake with EC(DHE) gives protection against active attackers. If 1313 a traffic secret has been compromised, any handshake with EC(DHE) 1314 gives protection against active attackers. 1316 The document "Confidentiality in the Face of Pervasive Surveillance: 1317 A Threat Model and Problem Statement" [RFC7624] defines key 1318 exfiltration as the transmission of cryptographic keying material for 1319 an encrypted communication from a collaborator, deliberately or 1320 unwittingly, to an attacker. Using the terms in RFC 7624, forward 1321 secrecy without rerunning EC(DHE) still allows an attacker to do 1322 static key exfiltration. Rerunning EC(DHE) forces and attacker to 1323 dynamic key exfiltration (or content exfiltration). 1325 When using DTLS 1.3 [I-D.ietf-tls-dtls13], AEAD limits and forward 1326 secrecy can be achieved by sending post-handshake KeyUpdate messages, 1327 which triggers rekeying of DTLS. Such symmetric rekeying gives 1328 significantly less protection against key leakage than re-running 1329 Diffie-Hellman as explained above. After leakage of 1330 application_traffic_secret_N, an attacker can passively eavesdrop on 1331 all future data sent on the connection including data encrypted with 1332 application_traffic_secret_N+1, application_traffic_secret_N+2, etc. 1333 Note that KeyUpdate does not update the exporter_secret. 1335 DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST 1336 (US), BSI (Germany), and ANSSI (France) recommends very frequent re- 1337 run of Diffie-Hellman to provide forward secrecy and force attackers 1338 to dynamic key extraction [RFC7624]. ANSSI writes "It is recommended 1339 to force the periodic renewal of the keys, e.g., every hour and every 1340 100 GB of data, in order to limit the impact of a key compromise." 1341 [ANSSI-DAT-NT-003]. 1343 For many DTLS/SCTP deployments the SCTP association is expected to 1344 have a very long lifetime of months or even years. For associations 1345 with such long lifetimes there is a need to frequently re- 1346 authenticate both client and server. TLS Certificate lifetimes 1347 significantly shorter than a year are common which is shorter than 1348 many expected DTLS/SCTP associations. 1350 SCTP-AUTH re-rekeying, periodic authentication of both endpoints, and 1351 frequent re-run of Diffie-Hellman to force attackers to dynamic key 1352 extraction is in DTLS/SCTP per this specification achieved by setting 1353 up new DTLS connections over the same SCTP association. 1354 Implementations SHOULD set up new connections frequently to force 1355 attackers to dynamic key extraction. Implementations MUST set up new 1356 connections before any of the certificates expire. It is RECOMMENDED 1357 that all negotiated and exchanged parameters are the same except for 1358 the timestamps in the certificates. Clients and servers MUST NOT 1359 accept a change of identity during the setup of a new connections, 1360 but MAY accept negotiation of stronger algorithms and security 1361 parameters, which might be motivated by new attacks. 1363 Allowing new connections can enable denial-of-service attacks. The 1364 endpoints SHOULD limit the frequency of new connections. 1366 When DTLS/SCTP is used with DTLS 1.2 [RFC6347], the TLS Session Hash 1367 and Extended Master Secret Extension [RFC7627] MUST be used to 1368 prevent unknown key-share attacks where an attacker establishes the 1369 same key on several connections. DTLS 1.3 always prevents these 1370 kinds of attacks. The use of SCTP-AUTH then cryptographically binds 1371 new connections to the old connection. This together with mandatory 1372 mutual authentication (on the DTLS layer) and a requirement to not 1373 accept new identities mitigates MITM attacks that have plagued 1374 renegotiation [TRISHAKE]. 1376 9.2. Downgrade Attacks 1378 A peer supporting DTLS/SCTP according to this specification, DTLS/ 1379 SCTP according to [RFC6083] and/or SCTP without DTLS may be 1380 vulnerable to downgrade attacks where on on-path attacker interferes 1381 with the protocol setup to lower or disable security. If possible, 1382 it is RECOMMENDED that the peers have a policy only allowing DTLS/ 1383 SCTP according to this specification. 1385 9.3. Targeting DTLS Messages 1387 The DTLS handshake messages and other control messages, i.e. not 1388 application data can easily be identified when using DTLS 1.2 as 1389 their content type is not encrypted. With DTLS 1.3 there is no 1390 unprotected content type. However, they will sent with an PPID of 0 1391 if sent in their own SCTP user messages. Section 4.4 proposes a 1392 basic behavior that will stil make it easily for anyone to detect the 1393 DTLS messages that are not proteceted user messages. 1395 9.4. Authentication and Policy Decisions 1397 DTLS/SCTP MUST be mutually authenticated. Authentication is the 1398 process of establishing the identity of a user or system and 1399 verifying that the identity is valid. DTLS only provides proof of 1400 possession of a key. DTLS/SCTP MUST perform identity authentication. 1401 It is RECOMMENDED that DTLS/SCTP is used with certificate-based 1402 authentication. When certificates are used the applicatication using 1403 DTLS/SCTP is reposible for certificate policies, certificate chain 1404 validation, and identity authentication (HTTPS does for example match 1405 the hostname with a subjectAltName of type dNSName). The application 1406 using DTLS/SCTP MUST define what the identity is and how it is 1407 encoded and the client and server MUST use the same identity format. 1408 Guidance on server certificate validation can be found in [RFC6125]. 1409 DTLS/SCTP enables periodic transfer of mutual revocation information 1410 (OSCP stapling) every time a new parallel connection is set up. All 1411 security decisions MUST be based on the peer's authenticated 1412 identity, not on its transport layer identity. 1414 It is possible to authenticate DTLS endpoints based on IP addresses 1415 in certificates. SCTP associations can use multiple IP addresses per 1416 SCTP endpoint. Therefore, it is possible that DTLS records will be 1417 sent from a different source IP address or to a different destination 1418 IP address than that originally authenticated. This is not a problem 1419 provided that no security decisions are made based on the source or 1420 destination IP addresses. 1422 9.5. Resumption and Tickets 1424 In DTLS 1.3 any number of tickets can be issued in a connection and 1425 the tickets can be used for resumption as long as they are valid, 1426 which is up to seven days. The nodes in a resumed connection have 1427 the same roles (client or server) as in the connection where the 1428 ticket was issued. In DTLS/SCTP, there are no significant 1429 performance benefits with resumption and an implementation can chose 1430 to never issue any tickets. If tickets and resumption are used it is 1431 enough to issue a single ticket per connection. 1433 9.6. Privacy Considerations 1435 [RFC6973] suggests that the privacy considerations of IETF protocols 1436 be documented. 1438 For each SCTP user message, the user also provides a stream 1439 identifier, a flag to indicate whether the message is sent ordered or 1440 unordered, and a payload protocol identifier. Although DTLS/SCTP 1441 provides privacy for the actual user message, the other three 1442 information fields are not confidentiality protected. They are sent 1443 as cleartext because they are part of the SCTP DATA chunk header. 1445 It is RECOMMENDED that DTLS/SCTP is used with certificate based 1446 authentication in DTLS 1.3 [I-D.ietf-tls-dtls13] to provide identity 1447 protection. DTLS/SCTP MUST be used with a key exchange method 1448 providing forward secrecy. 1450 9.7. Pervasive Monitoring 1452 As required by [RFC7258], work on IETF protocols needs to consider 1453 the effects of pervasive monitoring and mitigate them when possible. 1455 Pervasive Monitoring is widespread surveillance of users. By 1456 encrypting more information including user identities, DTLS 1.3 1457 offers much better protection against pervasive monitoring. 1459 Massive pervasive monitoring attacks relying on key exchange without 1460 forward secrecy has been reported. By mandating forward secrecy, 1461 DTLS/SCTP effectively mitigate many forms of passive pervasive 1462 monitoring and limits the amount of compromised data due to key 1463 compromise. 1465 An important mitigation of pervasive monitoring is to force attackers 1466 to do dynamic key exfiltration instead of static key exfiltration. 1467 Dynamic key exfiltration increases the risk of discovery for the 1468 attacker [RFC7624]. DTLS/SCTP per this specification encourages 1469 implementations to frequently set up new DTLS connections with 1470 (EC)DHE over the same SCTP association to force attackers to do 1471 dynamic key exfiltration. 1473 In addition to the privacy attacks discussed above, surveillance on a 1474 large scale may enable tracking of a user over a wider geographical 1475 area and across different access networks. Using information from 1476 DTLS/SCTP together with information gathered from other protocols 1477 increase the risk of identifying individual users. 1479 10. Contributors 1481 Michael Tuexen contributed as co-author to the intitial versions this 1482 draft. Michael's contributions include: 1484 * The use of the Adaptation Layer Indication. 1486 * Socket API extension 1488 * Many editorial improvements. 1490 11. Acknowledgments 1492 The authors of RFC 6083 which this document is based on are Michael 1493 Tuexen, Eric Rescorla, and Robin Seggelmann. 1495 The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry 1496 Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan 1497 Lindskog, Daniel Mentz, and Sean Turner for their invaluable 1498 comments. 1500 The authors of this document want to thank Daria Ivanova, Li Yan, and 1501 GitHub user vanrein for their contribution. 1503 12. References 1505 12.1. Normative References 1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1508 Requirement Levels", BCP 14, RFC 2119, 1509 DOI 10.17487/RFC2119, March 1997, 1510 . 1512 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1513 Conrad, "Stream Control Transmission Protocol (SCTP) 1514 Partial Reliability Extension", RFC 3758, 1515 DOI 10.17487/RFC3758, May 2004, 1516 . 1518 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1519 "Authenticated Chunks for the Stream Control Transmission 1520 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1521 2007, . 1523 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1524 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1525 . 1527 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1528 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1529 March 2010, . 1531 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1532 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1533 January 2012, . 1535 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 1536 Langley, A., and M. Ray, "Transport Layer Security (TLS) 1537 Session Hash and Extended Master Secret Extension", 1538 RFC 7627, DOI 10.17487/RFC7627, September 2015, 1539 . 1541 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1542 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1543 DOI 10.17487/RFC7540, May 2015, 1544 . 1546 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1547 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1548 May 2017, . 1550 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1551 "Stream Schedulers and User Message Interleaving for the 1552 Stream Control Transmission Protocol", RFC 8260, 1553 DOI 10.17487/RFC8260, November 2017, 1554 . 1556 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1557 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1558 . 1560 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1561 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1562 . 1564 [I-D.ietf-tls-dtls13] 1565 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1566 Datagram Transport Layer Security (DTLS) Protocol Version 1567 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1568 dtls13-43, 30 April 2021, . 1571 [I-D.ietf-tls-dtls-connection-id] 1572 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 1573 "Connection Identifiers for DTLS 1.2", Work in Progress, 1574 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 1575 June 2021, . 1578 12.2. Informative References 1580 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1581 Layer Security over Stream Control Transmission Protocol", 1582 RFC 3436, DOI 10.17487/RFC3436, December 2002, 1583 . 1585 [RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, 1586 "Security Considerations for Signaling Transport (SIGTRAN) 1587 Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004, 1588 . 1590 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1591 Kozuka, "Stream Control Transmission Protocol (SCTP) 1592 Dynamic Address Reconfiguration", RFC 5061, 1593 DOI 10.17487/RFC5061, September 2007, 1594 . 1596 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1597 Transport Layer Security (DTLS) for Stream Control 1598 Transmission Protocol (SCTP)", RFC 6083, 1599 DOI 10.17487/RFC6083, January 2011, 1600 . 1602 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1603 Verification of Domain-Based Application Service Identity 1604 within Internet Public Key Infrastructure Using X.509 1605 (PKIX) Certificates in the Context of Transport Layer 1606 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1607 2011, . 1609 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1610 Yasevich, "Sockets API Extensions for the Stream Control 1611 Transmission Protocol (SCTP)", RFC 6458, 1612 DOI 10.17487/RFC6458, December 2011, 1613 . 1615 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1616 Morris, J., Hansen, M., and R. Smith, "Privacy 1617 Considerations for Internet Protocols", RFC 6973, 1618 DOI 10.17487/RFC6973, July 2013, 1619 . 1621 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1622 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1623 2014, . 1625 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1626 Known Attacks on Transport Layer Security (TLS) and 1627 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1628 February 2015, . 1630 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1631 "Recommendations for Secure Use of Transport Layer 1632 Security (TLS) and Datagram Transport Layer Security 1633 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1634 2015, . 1636 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1637 Trammell, B., Huitema, C., and D. Borkmann, 1638 "Confidentiality in the Face of Pervasive Surveillance: A 1639 Threat Model and Problem Statement", RFC 7624, 1640 DOI 10.17487/RFC7624, August 2015, 1641 . 1643 [ANSSI-DAT-NT-003] 1644 Agence nationale de la sécurité des systèmes 1645 d'information, "Recommendations for securing networks with 1646 IPsec", ANSSI Technical Report DAT-NT-003 , August 2015, 1647 <>. 1650 [TRISHAKE] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 1651 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 1652 Breaking and Fixing Authentication over TLS", IEEE 1653 Symposium on Security & Privacy , April 2016, 1654 . 1657 Appendix A. Motivation for Changes 1659 This document proposes a number of changes to RFC 6083 that have 1660 various different motivations: 1662 Supporting Large User Messages: RFC 6083 allowed only user messages 1663 that could fit within a single DTLS record. 3GPP has run into this 1664 limitation where they have at least four SCTP using protocols (F1, 1665 E1, Xn, NG-C) that can potentially generate messages over the size of 1666 16384 bytes. 1668 New Versions: Almost 10 years has passed since RFC 6083 was written, 1669 and significant evolution has happened in the area of DTLS and 1670 security algorithms. Thus DTLS 1.3 is the newest version of DTLS and 1671 also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end 1672 of usefulness. Use of DTLS 1.3 with long lived associations require 1673 parallel DTLS connections. Thus, this document mandates usage of 1674 relevant versions and algorithms. 1676 Allowing DTLS Messages on any stream: RFC6083 requires DTLS messages 1677 that are not user message data to sent on stream 0 and that this 1678 stream is used with in-order delivery. That can actually limit the 1679 applications that can use DTLS/SCTP. In addition with DTLS 1.3 1680 encrypting the actual message type it is anyway not available. 1681 Therefore a more flexible rule set is used that relies on DTLS 1682 handling reordering. 1684 Clarifications: Some implementation experiences have been gained that 1685 motivates additional clarifications on the specification. 1687 * Avoid unsecured messages prior to DTLS handshake have completed. 1689 * Make clear that all messages are encrypted after DTLS handshake. 1691 Authors' Addresses 1693 Magnus Westerlund 1694 Ericsson 1695 Email: magnus.westerlund@ericsson.com 1696 John Preuß Mattsson 1697 Ericsson 1698 Email: john.mattsson@ericsson.com 1700 Claudio Porfiri 1701 Ericsson 1702 Email: claudio.porfiri@ericsson.com