idnits 2.17.1 draft-ietf-tsvwg-dtls-over-sctp-bis-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(7): 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 7 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1214 lines 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 (12 July 2021) is 1016 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 875, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** 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 7525 (Obsoleted by RFC 9325) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: 13 January 2022 M. Tüxen 7 Münster Univ. of Appl. Sciences 8 12 July 2021 10 Datagram Transport Layer Security (DTLS) over Stream Control 11 Transmission Protocol (SCTP) 12 draft-ietf-tsvwg-dtls-over-sctp-bis-01 14 Abstract 16 This document describes a proposed update for the usage of the 17 Datagram Transport Layer Security (DTLS) protocol to protect user 18 messages sent over the Stream Control Transmission Protocol (SCTP). 20 DTLS over SCTP provides mutual authentication, confidentiality, 21 integrity protection, and replay protection for applications that use 22 SCTP as their transport protocol and allows client/server 23 applications to communicate in a way that is designed to give 24 communications privacy and to prevent eavesdropping and detect 25 tampering or message forgery. 27 Applications using DTLS over SCTP can use almost all transport 28 features provided by SCTP and its extensions. This document intends 29 to obsolete RFC 6083 and removes the 16 kB limitation on user message 30 size by defining a secure user message fragmentation so that multiple 31 DTLS records can be used to protect a single user message. It 32 further updates the DTLS versions to use, as well as the HMAC 33 algorithms for SCTP-AUTH, and simplifies secure implementation by 34 some stricter requirements on the establishment procedures. 36 Discussion Venues 38 This note is to be removed before publishing as an RFC. 40 Discussion of this document takes place on the TSVWG Working Group 41 mailing list (tsvwg@ietf.org), which is archived at 42 https://mailarchive.ietf.org/arch/browse/tsvwg/. 44 Source for this draft and an issue tracker can be found at 45 https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on 13 January 2022. 64 Copyright Notice 66 Copyright (c) 2021 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 71 license-info) in effect on the date of publication of this document. 72 Please review these documents carefully, as they describe your rights 73 and restrictions with respect to this document. Code Components 74 extracted from this document must include Simplified BSD License text 75 as described in Section 4.e of the Trust Legal Provisions and are 76 provided without warranty as described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction 81 1.1. Overview 82 1.1.1. Comparison with TLS for SCTP 83 1.1.2. Changes from RFC 6083 84 1.2. DTLS Version 85 1.3. Terminology 86 1.4. Abbreviations 87 2. Conventions 88 3. DTLS Considerations 89 3.1. Version of DTLS 90 3.2. Cipher Suites and Cryptographic Parameters 91 3.3. Message Sizes 92 3.4. Replay Protection 93 3.5. Path MTU Discovery 94 3.6. Retransmission of Messages 95 4. SCTP Considerations 96 4.1. Mapping of DTLS Records 97 4.2. DTLS Connection Handling 98 4.3. Payload Protocol Identifier Usage 99 4.4. Stream Usage 100 4.5. Chunk Handling 101 4.6. SCTP-AUTH Hash Function 102 4.7. Renegotiation 103 4.7.1. DTLS 1.2 Considerations 104 4.7.2. DTLS 1.3 Considerations 105 4.8. DTLS Epochs 106 4.8.1. DTLS 1.2 Considerations 107 4.8.2. DTLS 1.3 Considerations 108 4.9. Handling of Endpoint-Pair Shared Secrets 109 4.9.1. DTLS 1.2 Considerations 110 4.9.2. DTLS 1.3 Considerations 111 4.10. Shutdown 112 5. DTLS over SCTP Service 113 5.1. Adaptation Layer Indication in INIT/INIT-ACK 114 5.2. DTLS over SCTP Initialization 115 5.3. Client Use Case 116 5.4. Server Use Case 117 5.5. RFC 6083 Fallback 118 6. Socket API Considerations 119 6.1. Socket Option to Get the HMAC Identifier being Sent 120 (SCTP_SEND_HMAC_IDENT) 121 6.2. Exposing the HMAC Identifiers being Received 122 6.3. Socket Option to Expose HMAC Identifier Usage 123 (SCTP_EXPOSE_HMAC_IDENT_CHANGES) 124 7. IANA Considerations 125 7.1. TLS Exporter Label 126 7.2. SCTP Adaptation Layer Indication Code Point 127 8. Security Considerations 128 8.1. Cryptographic Considerations 129 8.2. Downgrade Attacks 130 8.3. Authentication and Policy Decisions 131 8.4. Privacy Considerations 132 8.5. Pervasive Monitoring 133 9. Acknowledgments 134 10. References 135 10.1. Normative References 136 10.2. Informative References 137 Appendix A. Motivation for Changes 138 Authors' Addresses 140 1. Introduction 142 1.1. Overview 144 This document describes the usage of the Datagram Transport Layer 145 Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS 146 1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission 147 Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks 148 for SCTP (SCTP-AUTH) [RFC4895]. 150 This specification provides mutual authentication of endpoints, 151 confidentiality, integrity protection, and replay protection of user 152 messages for applications that use SCTP as their transport protocol. 153 Thus, it allows client/server applications to communicate in a way 154 that is designed to give communications privacy and to prevent 155 eavesdropping and detect tampering or message forgery. DTLS/SCTP 156 uses DTLS for mutual authentication, key exchange with perfect 157 forward secrecy for SCTP-AUTH, and confidentiality of user messages. 158 DTLS/SCTP use SCTP and SCTP-AUTH for integrity protection and replay 159 protection of user messages. 161 Applications using DTLS over SCTP can use almost all transport 162 features provided by SCTP and its extensions. DTLS/SCTP supports: 164 * preservation of message boundaries. 166 * a large number of unidirectional and bidirectional streams. 168 * ordered and unordered delivery of SCTP user messages. 170 * the partial reliability extension as defined in [RFC3758]. 172 * the dynamic address reconfiguration extension as defined in 173 [RFC5061]. 175 * large user messages. 177 The method described in this document requires that the SCTP 178 implementation supports the optional feature of fragmentation of SCTP 179 user messages as defined in [RFC4960]. The implementation is also 180 required to have an SCTP API (for example the one described in 181 [RFC6458]) that supports partial user message delivery and also 182 recommended that I-DATA chunks as defined in [RFC8260] is used to 183 efficiently implement and support larger user messages. 185 To simplify implementation and reduce the risk for security holes, 186 limitations have been defined such that STARTTLS as specified in 187 [RFC3788] is no longer supported. 189 1.1.1. Comparison with TLS for SCTP 191 TLS, from which DTLS was derived, is designed to run on top of a 192 byte-stream-oriented transport protocol providing a reliable, in- 193 sequence delivery. TLS over SCTP as described in [RFC3436] has some 194 serious limitations: 196 * It does not support the unordered delivery of SCTP user messages. 198 * It does not support partial reliability as defined in [RFC3758]. 200 * It only supports the usage of the same number of streams in both 201 directions. 203 * It uses a TLS connection for every bidirectional stream, which 204 requires a substantial amount of resources and message exchanges 205 if a large number of streams is used. 207 1.1.2. Changes from RFC 6083 209 The DTLS over SCTP solution defined in RFC 6083 had the following 210 limitation: 212 * The maximum user message size is 2^14 bytes, which is a single 213 DTLS record limit. 215 This update that replaces RFC 6083 defines the following changes: 217 * Removes the limitations on user messages sizes by defining a 218 secure fragmentation mechanism. 220 * Mandates that more modern DTLS version are required (DTLS 1.2 or 221 1.3) 223 * Mandates use of modern HMAC algorithm (SHA-256) in the SCTP 224 authentication extension [RFC4895]. 226 * Recommends support of [RFC8260] to enable interleaving of large 227 SCTP user messages to avoid scheduling issues. 229 * Applies stricter requirements on always using DTLS for all user 230 messages in the SCTP association. 232 * Requires that SCTP-AUTH is applied to all SCTP Chunks that can be 233 authenticated. 235 * Requires support of partial delivery of user messages. 237 Mandating DTLS 1.2 or DTLS 1.3 instead to using DTLS 1.0 limits the 238 lifetime of a DTLS connection and the data volume which can be 239 transferred over a DTLS connection. This is cause by: 241 * The number of renegotiations in DTLS 1.2 is limited to 65534 242 compared to unlimited in DTLS 1.0. 244 * The number of KeyUpdates in DTLS 1.3 is limited to 65532 and 245 renegotiations are not supported. 247 1.2. DTLS Version 249 DTLS/SCTP as defined by this document can use either DTLS 1.2 250 [RFC6347] or DTLS 1.3 [I-D.ietf-tls-dtls13]. Some crucial difference 251 between the DTLS versions make it necessary for a user of DTLS/SCTP 252 to make an informed choice of the DTLS version to use based on their 253 application's requirements. In general, DTLS 1.3 is to preferred 254 being a newer protocol that addresses known vulnerabilities and only 255 defines strong algorithms without known major weaknesses at the time 256 of publication. 258 However, some applications using DTLS/SCTP are of semi-permanent 259 nature and use SCTP associations with lifetimes that are more than a 260 few hours, and where there is a significant cost of bringing down the 261 SCTP association in order to restart it. For such DTLS/SCTP usages 262 that need either of: 264 * Periodic re-authentication of both endpoints (not only the DTLS 265 client). 267 * Periodic rerunning of Diffie-Hellman key-exchange to provide 268 Perfect Forward Secrecy (PFS) to reduce the impact any key-reveal. 270 * Perform SCTP-AUTH re-keying. 272 At the time of publication DTLS 1.3 does not support any of these, 273 where DTLS 1.2 renegotiation functionality can provide this 274 functionality in the context of DTLS/SCTP. The application will have 275 to analyze its needs and requirements on the above and based on this 276 select the DTLS version to use. 278 To address known vulnerabilities in DTLS 1.2 this document describes 279 and mandates implementation constraints on ciphers, protocol options 280 and how to use the DTLS renegotiation mechanism. 282 In the rest of the document, unless the version of DTLS is 283 specifically called out the text applies to both versions of DTLS. 285 1.3. Terminology 287 This document uses the following terms: 289 Association: An SCTP association. 291 Stream: A unidirectional stream of an SCTP association. It is 292 uniquely identified by a stream identifier. 294 1.4. Abbreviations 296 DTLS: Datagram Transport Layer Security 298 MTU: Maximum Transmission Unit 300 PFS: Perfect Forward Secrecy 302 PPID: Payload Protocol Identifier 304 SCTP: Stream Control Transmission Protocol 306 TCP: Transmission Control Protocol 308 TLS: Transport Layer Security 310 ULP: Upper Layer Protocol 312 2. Conventions 314 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 315 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 316 "OPTIONAL" in this document are to be interpreted as described in BCP 317 14 [RFC2119] [RFC8174] when, and only when, they appear in all 318 capitals, as shown here. 320 3. DTLS Considerations 322 3.1. Version of DTLS 324 This document defines the usage of either DTLS 1.3 325 [I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of 326 DTLS MUST NOT be used (see [RFC8996]). It is expected that DTLS/SCTP 327 as described in this document will work with future versions of DTLS. 329 3.2. Cipher Suites and Cryptographic Parameters 331 For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be 332 used. For all versions of DTLS, cryptographic parameters giving 333 confidentiality and Perfect Forward Secrecy (PFS) MUST be used. 335 3.3. Message Sizes 337 DTLS/SCTP, automatically fragments and reassembles user messages. 338 This specification defines how to fragment the user messages into 339 DTLS records, where each DTLS 1.3 record allows a maximum of 2^14 340 protected bytes. Each DTLS record adds some overhead, thus using 341 records of maximum possible size are recommended to minimize the 342 transmitted overhead. 344 The sequence of DTLS records is then fragmented into DATA or I-DATA 345 Chunks to fit the path MTU by SCTP. The largest possible user 346 messages using the mechanism defined in this specification is 2^64-1 347 bytes. 349 The security operations and reassembly process requires that the 350 protected user message, i.e., with DTLS record overhead, is buffered 351 in the receiver. This buffer space will thus put a limit on the 352 largest size of plain text user message that can be transferred 353 securely. However, by mandating the use of the partial delivery of 354 user messages from SCTP and assuming that no two messages received on 355 the same stream are interleaved (as it is the case when using the API 356 defined in [RFC6458]) the required buffering prior to DTLS processing 357 can be limited to a single DTLS record per used incoming stream. 358 This enables the DTLS/SCTP implementation to provide the Upper Layer 359 Protocol (ULP) with each DTLS record's content when it has been 360 decrypted and its integrity been verified enabling partial user 361 message delivery to the ULP. Implementations can trade-off buffer 362 memory requirements in the DTLS layer with transport overhead by 363 using smaller DTLS records. 365 The DTLS/SCTP implementation is expected to behave very similar to 366 just SCTP when it comes to handling of user messages and dealing with 367 large user messages and their reassembly and processing. Making it 368 the ULP responsible for handling any resource contention related to 369 large user messages. 371 3.4. Replay Protection 373 SCTP-AUTH [RFC4895] does not have explicit replay protection. 374 However, the combination of SCTP-AUTH's protection of DATA or I-DATA 375 chunks and SCTP user message handling will prevent third party 376 attempts to inject or replay SCTP packets resulting in impact on the 377 received protected user message. In fact, this document's solution 378 is dependent on SCTP-AUTH and SCTP to prevent reordering, 379 duplication, and removal of the DTLS records within each protected 380 user message. This includes detection of changes to what DTLS 381 records start and end the SCTP user message, and removal of DTLS 382 records before an increment to the epoch. Without SCTP-AUTH, these 383 would all have required explicit handling. 385 DTLS optionally supports record replay detection. Such replay 386 detection could result in the DTLS layer dropping valid messages 387 received outside of the DTLS replay window. As DTLS/SCTP provides 388 replay protection even without DTLS replay protection, the replay 389 detection of DTLS MUST NOT be used. 391 3.5. Path MTU Discovery 393 DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides Path 394 MTU discovery and fragmentation/reassembly for user messages, and 395 according to Section 3.3, DTLS can send maximum sized DTLS Records. 397 3.6. Retransmission of Messages 399 SCTP provides a reliable and in-sequence transport service for DTLS 400 messages that require it. See Section 4.4. Therefore, DTLS 401 procedures for retransmissions MUST NOT be used. 403 4. SCTP Considerations 405 4.1. Mapping of DTLS Records 407 The SCTP implementation MUST support fragmentation of user messages 408 using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks. 410 DTLS/SCTP works as a shim layer between the user message API and 411 SCTP. The fragmentation works similar as the DTLS fragmentation of 412 handshake messages. On the sender side a user message fragmented 413 into fragments m0, m1, m2, each no larger than 2^14 - 1 = 16383 414 bytes. 416 m0 | m1 | m2 | ... = user_message 418 The resulting fragments are protected with DTLS and the records are 419 concatenated 421 user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ... 423 The new user_message', i.e., the protected user message, is the input 424 to SCTP. 426 On the receiving side DTLS is used to decrypt the individual records. 427 There are three failure cases an implementation needs to detect and 428 then act on: 430 1. Failure in decryption and integrity verification process of any 431 DTLS record. Due to SCTP-AUTH preventing delivery of injected or 432 corrupt fragments of the protected user message this should only 433 occur in case of implementation errors or internal hardware 434 failures. 436 2. In case the SCTP layer indicates an end to a user message, e.g. 437 when receiving a MSG_EOR in a recvmsg() call when using the API 438 described in [RFC6458], and the last buffered DTLS record length 439 field does not match, i.e., the DTLS record is incomplete. 441 3. Unable to perform the decryption processes due to lack of 442 resources, such as memory, and have to abandon the user message 443 fragment. This specification is defined such that the needed 444 resources for the DTLS/SCTP operations are bounded for a given 445 number of concurrent transmitted SCTP streams or unordered user 446 messages. 448 The above failure cases all result in the receiver failing to 449 recreate the full user message. This is a failure of the transport 450 service that is not possible to recover from in the DTLS/SCTP layer 451 and the sender could believe the complete message have been 452 delivered. This error MUST NOT be ignored, as SCTP lacks any 453 facility to declare a failure on a specific stream or user message, 454 the DTLS connection and the SCTP association SHOULD be terminated. A 455 valid exception to the termination of the SCTP association is if the 456 receiver is capable of notifying the ULP about the failure in 457 delivery and the ULP is capable of recovering from this failure. 459 Note that if the SCTP extension for Partial Reliability (PR-SCTP) 460 [RFC3758] is used for a user message, user message may be partially 461 delivered or abandoned. These failures are not a reason for 462 terminating the DTLS connection and SCTP association. 464 The DTLS Connection ID SHOULD NOT be negotiated (Section 9 of 465 [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field MUST 466 be included and a 16-bit sequence number SHOULD be used. 468 4.2. DTLS Connection Handling 470 The DTLS connection MUST be established at the beginning of the SCTP 471 association and be terminated when the SCTP association is 472 terminated, (i.e., there's only one DTLS connection within one 473 association). A DTLS connection MUST NOT span multiple SCTP 474 associations. 476 As it is required to establish the DTLS connection at the beginning 477 of the SCTP association, either of the peers should never send any 478 SCTP user messages that are not protected by DTLS. So, the case that 479 an endpoint receives data that is not either DTLS messages on Stream 480 0 or protected user messages in the form of a sequence of DTLS 481 Records on any stream is a protocol violation. The receiver MAY 482 terminate the SCTP association due to this protocol violation. 484 4.3. Payload Protocol Identifier Usage 486 SCTP Payload Protocol Identifiers are assigned by IANA. Application 487 protocols using DTLS over SCTP SHOULD register and use a separate 488 Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that 489 they registered for running directly over SCTP. 491 Using the same PPID does not harm as long as the application can 492 determine whether or not DTLS is used. However, for protocol 493 analyzers, for example, it is much easier if a separate PPID is used. 495 This means, in particular, that there is no specific PPID for DTLS. 497 4.4. Stream Usage 499 All DTLS Handshake, Alert, or ChangeCipherSpec (DTLS 1.2 only) 500 messages MUST be transported on stream 0 with unlimited reliability 501 and with the ordered delivery feature. 503 DTLS messages of the record protocol, which carries the protected 504 user messages, SHOULD use multiple streams other than stream 0; they 505 MAY use stream 0. On stream 0 protected user messages as well as any 506 DTLS messages that aren't record protocol will be mixed, thus the 507 additional head of line blocking can occur. 509 4.5. Chunk Handling 511 DATA chunks of SCTP MUST be sent in an authenticated way as described 512 in [RFC4895]. All other chunks that can be authenticated, i.e., all 513 chunk types that can be listed in the Chunk List Parameter [RFC4895], 514 MUST also be sent in an authenticated way. This makes sure that an 515 attacker cannot modify the stream in which a message is sent or 516 affect the ordered/unordered delivery of the message. 518 If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST 519 also be sent in an authenticated way as described in [RFC4895]. This 520 makes sure that it is not possible for an attacker to drop messages 521 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this 522 dropping. 524 I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be 525 supported to avoid some of the down sides that large user messages 526 have on blocking transmission of later arriving high priority user 527 messages. However, the support is not mandated and negotiated 528 independently from DTLS/SCTP. If I-DATA chunks are used, then they 529 MUST be sent in an authenticated way as described in [RFC4895]. 531 4.6. SCTP-AUTH Hash Function 533 When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be 534 supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT 535 be used when using DTLS/SCTP. [RFC4895] requires support and 536 inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both 537 requirements the HMAC-ALGO parameter will include both SHA-256 and 538 SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference. 540 4.7. Renegotiation 542 DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie- 543 Hellman) of both DTLS and SCTP-AUTH as well as mutual 544 reauthentication inside an DTLS 1.2 connection. It is up to the 545 upper layer to use/allow it or not. Application writers should be 546 aware that allowing renegotiations may result in changes of security 547 parameters. Renegotiation has been removed from DTLS 1.3 and partly 548 replaced with post-handshake messages such as KeyUpdate. See 549 Section 8 for security considerations regarding rekeying. 551 4.7.1. DTLS 1.2 Considerations 553 Before sending during renegotiation a ClientHello message or 554 ServerHello message, the DTLS endpoint MUST ensure that all DTLS 555 messages using the previous epoch have been acknowledged by the SCTP 556 peer in a non-revokable way. 558 Prior to processing a received ClientHello message or ServerHello 559 message, all other received SCTP user messages that are buffered in 560 the SCTP layer and can be delivered to the DTLS layer MUST be read 561 and processed by DTLS. 563 4.7.2. DTLS 1.3 Considerations 565 Before sending a KeyUpdate message, the DTLS endpoint MUST ensure 566 that all DTLS messages have been acknowledged by the SCTP peer in a 567 non-revokable way. After sending the KeyUpdate message, it stops 568 sending DTLS messages until the corresponding Ack message has been 569 processed. 571 Prior to processing a received KeyUpdate message, all other received 572 SCTP user messages that are buffered in the SCTP layer and can be 573 delivered to the DTLS layer MUST be read and processed by DTLS. 575 4.8. DTLS Epochs 577 In general, DTLS implementations SHOULD discard records from earlier 578 epochs. However, in the context of a reliable communication this is 579 not appropriate. 581 4.8.1. DTLS 1.2 Considerations 583 The procedures of Section 4.1 of [RFC6347] MUST NOT be followed. 584 Instead, when currently using epoch n, for n > 1, DTLS packets from 585 epoch n - 1 and n MUST be processed. 587 4.8.2. DTLS 1.3 Considerations 589 The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are 590 irrelevant. When receiving DTLS packets using epoch n, no DTLS 591 packets from earlier epochs are received. 593 4.9. Handling of Endpoint-Pair Shared Secrets 595 SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In 596 SCTP associations where DTLS is used, DTLS is used to establish these 597 secrets. The endpoints MUST NOT use another mechanism for 598 establishing shared secrets for SCTP-AUTH. The endpoint-pair shared 599 secret for Shared Key Identifier 0 is empty and MUST be used when 600 establishing a DTLS connection. 602 4.9.1. DTLS 1.2 Considerations 604 Whenever the master secret changes, a 64-byte shared secret is 605 derived from every master secret and provided as a new endpoint-pair 606 shared secret by using the TLS-Exporter described in [RFC5705]. The 607 64-byte shared secret MUST be provided to the SCTP stack as soon as 608 the computation is possible. The exporter MUST use the label given 609 in Section Section 7 and no context. The new Shared Key Identifier 610 MUST be the old Shared Key Identifier incremented by 1. 612 After sending the DTLS Finished message, the active SCTP-AUTH key 613 MUST be switched to the new one. 615 Once the initial Finished message from the peer has been processed by 616 DTLS, the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed. 617 Once the Finished message using DTLS epoch n with n > 2 has been 618 processed by DTLS, the SCTP-AUTH key with Shared Key Identifier n - 2 619 MUST be removed. 621 4.9.2. DTLS 1.3 Considerations 623 When the exporter_secret can be computed, a 64-byte shared secret is 624 derived from it and provided as a new endpoint-pair shared secret by 625 using the TLS-Exporter described in [RFC8446]. The 64-byte shared 626 secret MUST be provided to the SCTP stack as soon as the computation 627 is possible. The exporter MUST use the label given in 628 Section Section 7 and no context. This shared secret MUST use Shared 629 Key Identifier 1. 631 After sending the DTLS Finished message, the active SCTP-AUTH key 632 MUST be switched to use Shared Key Identifier 1. 634 Once the Finished message from the peer has been processed by DTLS, 635 the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed. 637 4.10. Shutdown 639 To prevent DTLS from discarding DTLS user messages while it is 640 shutting down, a CloseNotify message MUST only be sent after all 641 outstanding SCTP user messages have been acknowledged by the SCTP 642 peer in a non-revokable way. 644 Prior to processing a received CloseNotify, all other received SCTP 645 user messages that are buffered in the SCTP layer MUST be read and 646 processed by DTLS. 648 5. DTLS over SCTP Service 650 The adoption of DTLS over SCTP according to the current description 651 is meant to add to SCTP the option for transferring encrypted data. 652 When DTLS over SCTP is used, all data being transferred MUST be 653 protected by chunk authentication and DTLS encrypted. Chunks that 654 need to be received in an authenticated way will be specified in the 655 CHUNK list parameter according to [RFC4895]. Error handling for 656 authenticated chunks is according to [RFC4895]. 658 5.1. Adaptation Layer Indication in INIT/INIT-ACK 660 At the initialization of the association, a sender of the INIT or 661 INIT ACK chunk that intends to use DTLS/SCTP as specified in this 662 specification MUST include an Adaptation Layer Indication Parameter 663 with the IANA assigned value TBD (Section 7.2) to inform its peer 664 that it is able to support DTLS over SCTP per this specification. 666 5.2. DTLS over SCTP Initialization 668 Initialization of DTLS/SCTP requires all the following options to be 669 part of the INIT/INIT-ACK handshake: 671 RANDOM: defined in [RFC4895] 673 CHUNKS: list of permitted chunks, defined in [RFC4895] 675 HMAC-ALGO: defined in [RFC4895] 677 ADAPTATION-LAYER-INDICATION: defined in [RFC5061] 679 When all the above options are present, the Association will start 680 with support of DTLS/SCTP. The set of options indicated are the 681 DTLS/SCTP Mandatory Options. No data transfer is permitted before 682 DTLS handshake is complete. Chunk bundling is permitted according to 683 [RFC4960]. The DTLS handshake will enable authentication of both the 684 peers and also have the declare their support message size. 686 The extension described in this document is given by the following 687 message exchange. 689 --- INIT[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] ---> 690 <- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] - 691 ------------------------ COOKIE-ECHO ------------------------> 692 <------------------------ COOKIE-ACK ------------------------- 693 ---------------- AUTH; DATA[DTLS Handshake] -----------------> 694 ... 695 ... 696 <--------------- AUTH; DATA[DTLS Handshake] ------------------ 698 5.3. Client Use Case 700 When a client initiates an SCTP Association with DTLS protection, 701 i.e., the SCTP INIT containing DTSL/SCTP Mandatory Options, it can 702 receive an INIT-ACK also containing DTLS/SCTP Mandatory Options, in 703 that case the Association will proceed as specified in the previous 704 Section 5.2 section. If the peer replies with an INIT-ACK not 705 containing all DTLS/SCTP Mandatory Options, the client SHOULD reply 706 with an SCTP ABORT. 708 5.4. Server Use Case 710 If a SCTP Server supports DTLS/SCTP, i.e., per this specification, 711 when receiving an INIT chunk with all DTLS/SCTP Mandatory Options it 712 will reply with an INIT-ACK also containing all the DTLS/SCTP 713 Mandatory Options, following the sequence for DTLS initialization 714 Section 5.2 and the related traffic case. If a SCTP Server that 715 supports DTLS and configured to use it, receives an INIT chunk 716 without all DTLS/SCTP Mandatory Options, it SHOULD reply with an SCTP 717 ABORT. 719 5.5. RFC 6083 Fallback 721 This section discusses how an endpoint supporting this specification 722 can fallback to follow the DTLS/SCTP behavior in RFC6083. It is 723 recommended to define a setting that represents the policy to allow 724 fallback or not. However, the possibility to use fallback is based 725 on the ULP can operate using user messages that are no longer than 726 16383 bytes and where the security issues can be mitigated or 727 considered acceptable. Fallback is NOT RECOMMEND to be enabled as it 728 enables downgrade to weaker algorithms and versions of DTLS. 730 An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk 731 that does not contain the SCTP-Adaptation-Indication parameter with 732 the DTLS/SCTP adaptation layer codepoint, see Section 7.2, may in 733 certain cases potentially perform a fallback to RFC 6083 behavior. 734 However, the fallback attempt should only be performed if policy says 735 that is acceptable. 737 If fallback is allowed, it is possible that the client will send 738 plain text user messages prior to DTLS handshake as it is allowed per 739 RFC 6083. So that needs to be part of the consideration for a policy 740 allowing fallback. 742 6. Socket API Considerations 744 This section describes how the socket API defined in [RFC6458] is 745 extended to provide a way for the application to observe the HMAC 746 algorithms used for sending and receiving of AUTH chunks. 748 Please note that this section is informational only. 750 A socket API implementation based on [RFC6458] is, by means of the 751 existing SCTP_AUTHENTICATION_EVENT event, extended to provide the 752 event notification whenever a new HMAC algorithm is used in a 753 received AUTH chunk. 755 Furthermore, two new socket options for the level IPPROTO_SCTP and 756 the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are 757 defined as described below. The first socket option is used to query 758 the HMAC algorithm used for sending AUTH chunks. The second enables 759 the monitoring of HMAC algorithms used in received AUTH chunks via 760 the SCTP_AUTHENTICATION_EVENT event. 762 Support for the SCTP_SEND_HMAC_IDENT and 763 SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also needs to be added 764 to the function sctp_opt_info(). 766 6.1. Socket Option to Get the HMAC Identifier being Sent 767 (SCTP_SEND_HMAC_IDENT) 769 During the SCTP association establishment a HMAC Identifier is 770 selected which is used by an SCTP endpoint when sending AUTH chunks. 771 An application can access the result of this selection by using this 772 read-only socket option, which uses the level IPPROTO_SCTP and the 773 name SCTP_SEND_HMAC_IDENT. 775 The following structure is used to access HMAC Identifier used for 776 sending AUTH chunks: 778 struct sctp_assoc_value { 779 sctp_assoc_t assoc_id; 780 uint32_t assoc_value; 781 }; 783 assoc_id: This parameter is ignored for one-to-one style sockets. 784 For one-to-many style sockets, the application fills in an 785 association identifier. It is an error to use 786 SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id. 788 assoc_value: This parameter contains the HMAC Identifier used for 789 sending AUTH chunks. 791 6.2. Exposing the HMAC Identifiers being Received 793 Section 6.1.8 of [RFC6458] defines the SCTP_AUTHENTICATION_EVENT 794 event, which uses the following structure: 796 struct sctp_authkey_event { 797 uint16_t auth_type; 798 uint16_t auth_flags; 799 uint32_t auth_length; 800 uint16_t auth_keynumber; 801 uint32_t auth_indication; 802 sctp_assoc_t auth_assoc_id; 803 }; 805 This document updates this structure to 807 struct sctp_authkey_event { 808 uint16_t auth_type; 809 uint16_t auth_flags; 810 uint32_t auth_length; 811 uint16_t auth_identifier; /* formerly auth_keynumber */ 812 uint32_t auth_indication; 813 sctp_assoc_t auth_assoc_id; 814 }; 816 by renaming auth_keynumber to auth_identifier. auth_identifier just 817 replaces auth_keynumber in the context of [RFC6458]. In addition to 818 that, the SCTP_AUTHENTICATION_EVENT event is extended to also 819 indicate when a new HMAC Identifier is received and such reporting is 820 explicitly enabled as described in Section 6.3. In this case 821 auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is 822 reported in auth_identifier. 824 6.3. Socket Option to Expose HMAC Identifier Usage 825 (SCTP_EXPOSE_HMAC_IDENT_CHANGES) 827 This options allows the application to enable and disable the 828 reception of SCTP_AUTHENTICATION_EVENT events when a new HMAC 829 Identifiers has been received in an AUTH chunk (see Section 6.2). 830 This read/write socket option uses the level IPPROTO_SCTP and the 831 name SCTP_EXPOSE_HMAC_IDENT_CHANGES. It is needed to provide 832 backwards compatibility and the default is that these events are not 833 reported. 835 The following structure is used to enable or disable the reporting of 836 newly received HMAC Identifiers in AUTH chunks: 838 struct sctp_assoc_value { 839 sctp_assoc_t assoc_id; 840 uint32_t assoc_value; 841 }; 843 assoc_id: This parameter is ignored for one-to-one style sockets. 844 For one-to-many style sockets, the application may fill in an 845 association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC. 847 assoc_value: Newly received HMAC Identifiers are reported if, and 848 only if, this parameter is non-zero. 850 7. IANA Considerations 852 7.1. TLS Exporter Label 854 RFC 6083 defined a TLS Exporter Label registry as described in 855 [RFC5705]. IANA is requested to update the reference for the label 856 "EXPORTER_DTLS_OVER_SCTP" to this specification. 858 7.2. SCTP Adaptation Layer Indication Code Point 860 [RFC5061] defined a IANA registry for Adaptation Code Points to be 861 used in the Adaptation Layer Indication parameter. The registry was 862 at time of writing located: https://www.iana.org/assignments/sctp- 863 parameters/sctp-parameters.xhtml#sctp-parameters-27 IANA is requested 864 to assign one Adaptation Code Point for DTLS/SCTP per the below 865 proposed entry in Table 1. 867 +============================+=============+===========+ 868 | Code Point (32-bit number) | Description | Reference | 869 +============================+=============+===========+ 870 | 0x00000002 | DTLS/SCTP | [RFC-TBD] | 871 +----------------------------+-------------+-----------+ 873 Table 1: Adaptation Code Point 875 RFC-Editor Note: Please replace [RFC-TBD] with the RFC number given 876 to this specification. 878 8. Security Considerations 880 The security considerations given in [I-D.ietf-tls-dtls13], 881 [RFC4895], and [RFC4960] also apply to this document. 883 8.1. Cryptographic Considerations 885 Over the years, there have been several serious attacks on earlier 886 versions of Transport Layer Security (TLS), including attacks on its 887 most commonly used ciphers and modes of operation. [RFC7457] 888 summarizes the attacks that were known at the time of publishing and 889 BCP 195 [RFC7525] provides recommendations for improving the security 890 of deployed services that use TLS. 892 When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be 893 configured to disable options known to provide insufficient security. 894 HTTP/2 [RFC7540] gives good minimum requirements based on the attacks 895 that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13] 896 only define strong algorithms without major weaknesses at the time of 897 publication. Many of the TLS registries have a "Recommended" column. 898 Parameters not marked as "Y" are NOT RECOMMENDED to support. 900 DTLS 1.3 requires rekeying before algorithm specific AEAD limits have 901 been reached. The AEAD limits equations are equally valid for DTLS 902 1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the 903 DTLS 1.2 specification. 905 HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and 906 very good integrity properties. The SCTP-AUTH key can be used until 907 the DTLS handshake is re-run at which point a new SCTP-AUTH key is 908 derived using the TLS-Exporter. As discussed below DTLS 1.3 does not 909 currently support renegotiation and lacks the capability of updating 910 the SCTP-AUTH key. 912 DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST 913 (US), BSI (Germany), and ANSSI (France) recommends very frequent re- 914 run of Diffie-Hellman to provide Perfect Forward Secrecy. ANSSI 915 writes "It is recommended to force the periodic renewal of the keys, 916 e.g., every hour and every 100 GB of data, in order to limit the 917 impact of a key compromise." [ANSSI-DAT-NT-003]. 919 For many DTLS/SCTP deployments the DTLS connections are expected to 920 have very long lifetimes of months or even years. For connections 921 with such long lifetimes there is a need to frequently re- 922 authenticate both client and server. 924 When using DTLS 1.2 [RFC6347], AEAD limits, frequent re- 925 authentication and frequent re-run of Diffie-Hellman can be achieved 926 with frequent renegotiation, see TLS 1.2 [RFC5246]. When 927 renegotiation is used both clients and servers MUST use the 928 renegotiation_info extension [RFC5746] and MUST follow the 929 renegotiation guidelines in BCP 195 [RFC7525]. In particular, both 930 clients and servers MUST NOT accept a change of identity during 931 renegotiation. 933 In DTLS 1.3 renegotiation has been removed from DTLS 1.3 and partly 934 replaced with Post-Handshake KeyUpdate. When using DTLS 1.3 935 [I-D.ietf-tls-dtls13], AEAD limits and frequent rekeying can be 936 achieved by sending frequent post-handshake KeyUpdate messages. 937 Symmetric rekeying gives less protection against key leakage than re- 938 running Diffie-Hellman. After leakage of 939 application_traffic_secret_N, a passive attacker can passively 940 eavesdrop on all future application data sent on the connection 941 including application data encrypted with 942 application_traffic_secret_N+1, application_traffic_secret_N+2, etc. 943 The is no way to do post-handshake server authentication or Ephemeral 944 Diffie-Hellman inside a DTLS 1.3 connection. Note that KeyUpdate 945 does not update the exporter_secret. 947 For upper layer protocols where frequent re-run of Diffie-Hellman, 948 rekeying of SCTP-AUTH, and server reauthentication is required and 949 creating a new SCTP connection with DTLS 1.3 to replace the current 950 is not a viable option it is RECOMMENDED to use DTLS 1.2. 952 8.2. Downgrade Attacks 954 A peer supporting DTLS/SCTP according to this specification, DTLS/ 955 SCTP according to [RFC6083] and/or SCTP without DTLS may be 956 vulnerable to downgrade attacks where on on-path attacker interferes 957 with the protocol setup to lower or disable security. If possible, 958 it is RECOMMENDED that the peers have a policy only allowing DTLS/ 959 SCTP according to this specification. 961 8.3. Authentication and Policy Decisions 963 DTLS/SCTP MUST be mutually authenticated. It is RECOMMENDED that 964 DTLS/SCTP is used with certificate-based authentication. All 965 security decisions MUST be based on the peer's authenticated 966 identity, not on its transport layer identity. 968 It is possible to authenticate DTLS endpoints based on IP addresses 969 in certificates. SCTP associations can use multiple IP addresses per 970 SCTP endpoint. Therefore, it is possible that DTLS records will be 971 sent from a different source IP address or to a different destination 972 IP address than that originally authenticated. This is not a problem 973 provided that no security decisions are made based on the source or 974 destination IP addresses. 976 8.4. Privacy Considerations 978 [RFC6973] suggests that the privacy considerations of IETF protocols 979 be documented. 981 For each SCTP user message, the user also provides a stream 982 identifier, a flag to indicate whether the message is sent ordered or 983 unordered, and a payload protocol identifier. Although DTLS/SCTP 984 provides privacy for the actual user message, the other three 985 information fields are not confidentiality protected. They are sent 986 as cleartext because they are part of the SCTP DATA chunk header. 988 It is RECOMMENDED that DTLS/SCTP is used with certificate based 989 authentication in DTLS 1.3 [I-D.ietf-tls-dtls13] to provide identity 990 protection. DTLS/SCTP MUST be used with a key exchange method 991 providing Perfect Forward Secrecy. Perfect Forward Secrecy 992 significantly limits the amount of data that can be compromised due 993 to key compromise. 995 8.5. Pervasive Monitoring 997 As required by [RFC7258], work on IETF protocols needs to consider 998 the effects of pervasive monitoring and mitigate them when possible. 1000 Pervasive Monitoring is widespread surveillance of users. By 1001 encrypting more information including user identities, DTLS 1.3 1002 offers much better protection against pervasive monitoring. 1004 Massive pervasive monitoring attacks relying on key exchange without 1005 forward secrecy has been reported. By mandating perfect forward 1006 secrecy, DTLS/SCTP effectively mitigate many forms of passive 1007 pervasive monitoring and limits the amount of compromised data due to 1008 key compromise. 1010 In addition to the privacy attacks discussed above, surveillance on a 1011 large scale may enable tracking of a user over a wider geographical 1012 area and across different access networks. Using information from 1013 DTLS/SCTP together with information gathered from other protocols 1014 increase the risk of identifying individual users. 1016 9. Acknowledgments 1018 The authors of RFC 6083 which this document is based on are Michael 1019 Tuexen, Eric Rescorla, and Robin Seggelmann. 1021 The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry 1022 Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan 1023 Lindskog, Daniel Mentz, and Sean Turner for their invaluable 1024 comments. 1026 The authors of this document want to thank GitHub user vanrein for 1027 their contribution. 1029 10. References 1031 10.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, 1035 DOI 10.17487/RFC2119, March 1997, 1036 . 1038 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 1039 Conrad, "Stream Control Transmission Protocol (SCTP) 1040 Partial Reliability Extension", RFC 3758, 1041 DOI 10.17487/RFC3758, May 2004, 1042 . 1044 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1045 "Authenticated Chunks for the Stream Control Transmission 1046 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 1047 2007, . 1049 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1050 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1051 . 1053 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1054 (TLS) Protocol Version 1.2", RFC 5246, 1055 DOI 10.17487/RFC5246, August 2008, 1056 . 1058 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1059 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1060 March 2010, . 1062 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1063 "Transport Layer Security (TLS) Renegotiation Indication 1064 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 1065 . 1067 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1068 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1069 January 2012, . 1071 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1072 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1073 DOI 10.17487/RFC7540, May 2015, 1074 . 1076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1078 May 2017, . 1080 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 1081 "Stream Schedulers and User Message Interleaving for the 1082 Stream Control Transmission Protocol", RFC 8260, 1083 DOI 10.17487/RFC8260, November 2017, 1084 . 1086 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1087 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1088 . 1090 [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1091 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1092 . 1094 [I-D.ietf-tls-dtls13] 1095 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1096 Datagram Transport Layer Security (DTLS) Protocol Version 1097 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1098 dtls13-43, 30 April 2021, . 1101 10.2. Informative References 1103 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 1104 Layer Security over Stream Control Transmission Protocol", 1105 RFC 3436, DOI 10.17487/RFC3436, December 2002, 1106 . 1108 [RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, 1109 "Security Considerations for Signaling Transport (SIGTRAN) 1110 Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004, 1111 . 1113 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1114 Kozuka, "Stream Control Transmission Protocol (SCTP) 1115 Dynamic Address Reconfiguration", RFC 5061, 1116 DOI 10.17487/RFC5061, September 2007, 1117 . 1119 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1120 Transport Layer Security (DTLS) for Stream Control 1121 Transmission Protocol (SCTP)", RFC 6083, 1122 DOI 10.17487/RFC6083, January 2011, 1123 . 1125 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 1126 Yasevich, "Sockets API Extensions for the Stream Control 1127 Transmission Protocol (SCTP)", RFC 6458, 1128 DOI 10.17487/RFC6458, December 2011, 1129 . 1131 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1132 Morris, J., Hansen, M., and R. Smith, "Privacy 1133 Considerations for Internet Protocols", RFC 6973, 1134 DOI 10.17487/RFC6973, July 2013, 1135 . 1137 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1138 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1139 2014, . 1141 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1142 Known Attacks on Transport Layer Security (TLS) and 1143 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1144 February 2015, . 1146 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1147 "Recommendations for Secure Use of Transport Layer 1148 Security (TLS) and Datagram Transport Layer Security 1149 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1150 2015, . 1152 [ANSSI-DAT-NT-003] 1153 Agence nationale de la sécurité des systèmes 1154 d'information, ., "Recommendations for securing networks 1155 with IPsec", ANSSI Technical Report DAT-NT-003 , August 1156 2015, <>. 1159 Appendix A. Motivation for Changes 1161 This document proposes a number of changes to RFC 6083 that have 1162 various different motivations: 1164 Supporting Large User Messages: RFC 6083 allowed only user messages 1165 that could fit within a single DTLS record. 3GPP has run into this 1166 limitation where they have at least four SCTP using protocols (F1, 1167 E1, Xn, NG-C) that can potentially generate messages over the size of 1168 16384 bytes. 1170 New Versions: Almost 10 years has passed since RFC 6083 was written, 1171 and significant evolution has happened in the area of DTLS and 1172 security algorithms. Thus DTLS 1.3 is the newest version of DTLS and 1173 also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end 1174 of usefulness. Thus, this document mandates usage of relevant 1175 versions and algorithms. 1177 Clarifications: Some implementation experiences have been gained that 1178 motivates additional clarifications on the specification. 1180 * Avoid unsecured messages prior to DTLS handshake have completed. 1182 * Make clear that all messages are encrypted after DTLS handshake. 1184 Authors' Addresses 1186 Magnus Westerlund 1187 Ericsson 1189 Email: magnus.westerlund@ericsson.com 1191 John Preuß Mattsson 1192 Ericsson 1194 Email: john.mattsson@ericsson.com 1196 Claudio Porfiri 1197 Ericsson 1199 Email: claudio.porfiri@ericsson.com 1201 Michael Tüxen 1202 Münster University of Applied Sciences 1203 Stegerwaldstrasse 39 1204 48565 Steinfurt 1205 Germany 1207 Email: tuexen@fh-muenster.de