idnits 2.17.1 draft-ietf-tls-dtls-connection-id-11.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6347, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6347, updated by this document, for RFC5378 checks: 2008-06-09) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (14 April 2021) is 1108 days in the past. Is this intentional? 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: 'ChangeCipherSpec' is mentioned on line 470, but not defined == Unused Reference: 'RFC5246' is defined on line 590, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-40 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla, Ed. 3 Internet-Draft RTFM, Inc. 4 Updates: 6347 (if approved) H. Tschofenig, Ed. 5 Intended status: Standards Track T. Fossati 6 Expires: 16 October 2021 Arm Limited 7 A. Kraus 8 Bosch.IO GmbH 9 14 April 2021 11 Connection Identifiers for DTLS 1.2 12 draft-ietf-tls-dtls-connection-id-11 14 Abstract 16 This document specifies the Connection ID (CID) construct for the 17 Datagram Transport Layer Security (DTLS) protocol version 1.2. 19 A CID is an identifier carried in the record layer header that gives 20 the recipient additional information for selecting the appropriate 21 security association. In "classical" DTLS, selecting a security 22 association of an incoming DTLS record is accomplished with the help 23 of the 5-tuple. If the source IP address and/or source port changes 24 during the lifetime of an ongoing DTLS session then the receiver will 25 be unable to locate the correct security context. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 16 October 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 74 3. The "connection_id" Extension . . . . . . . . . . . . . . . . 3 75 4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5 76 5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7 77 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 7 78 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 8 79 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 80 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 9 81 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 10.1. Extra Column to TLS ExtensionType Values Registry . . . 13 86 10.2. Entry to the TLS ExtensionType Values Registry . . . . . 13 87 10.3. Entry to the TLS ContentType Registry . . . . . . . . . 13 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 11.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 15 92 Appendix B. Working Group Information . . . . . . . . . . . . . 16 93 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 17 94 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 The Datagram Transport Layer Security (DTLS) [RFC6347] protocol was 100 designed for securing connection-less transports, like UDP. DTLS, 101 like TLS, starts with a handshake, which can be computationally 102 demanding (particularly when public key cryptography is used). After 103 a successful handshake, symmetric key cryptography is used to apply 104 data origin authentication, integrity and confidentiality protection. 105 This two-step approach allows endpoints to amortize the cost of the 106 initial handshake across subsequent application data protection. 107 Ideally, the second phase where application data is protected lasts 108 over a long period of time since the established keys will only need 109 to be updated once the key lifetime expires. 111 In DTLS as specified in RFC 6347, the IP address and port of the peer 112 are used to identify the DTLS association. Unfortunately, in some 113 cases, such as NAT rebinding, these values are insufficient. This is 114 a particular issue in the Internet of Things when devices enter 115 extended sleep periods to increase their battery lifetime. The NAT 116 rebinding leads to connection failure, with the resulting cost of a 117 new handshake. 119 This document defines an extension to DTLS 1.2 to add a CID to the 120 DTLS record layer. The presence of the CID is negotiated via a DTLS 121 extension. 123 2. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 129 capitals, as shown here. 131 This document assumes familiarity with DTLS 1.2 [RFC6347]. 133 3. The "connection_id" Extension 135 This document defines the "connection_id" extension, which is used in 136 ClientHello and ServerHello messages. 138 The extension type is specified as follows. 140 enum { 141 connection_id(TBD1), (65535) 142 } ExtensionType; 144 The extension_data field of this extension, when included in the 145 ClientHello, MUST contain the ConnectionId structure. This structure 146 contains the CID value the client wishes the server to use when 147 sending messages to the client. A zero-length CID value indicates 148 that the client is prepared to send with a CID but does not wish the 149 server to use one when sending. 151 struct { 152 opaque cid<0..2^8-1>; 153 } ConnectionId; 155 A server willing to use CIDs will respond with a "connection_id" 156 extension in the ServerHello, containing the CID it wishes the client 157 to use when sending messages towards it. A zero-length value 158 indicates that the server will send with the client's CID but does 159 not wish the client to include a CID. 161 Because each party sends the value in the "connection_id" extension 162 it wants to receive as a CID in encrypted records, it is possible for 163 an endpoint to use a globally constant length for such connection 164 identifiers. This can in turn ease parsing and connection lookup, 165 for example by having the length in question be a compile-time 166 constant. Such implementations MUST still be able to send CIDs of 167 different length to other parties. Implementations that want to use 168 variable-length CIDs are responsible for constructing the CID in such 169 a way that its length can be determined on reception. Note that 170 there is no CID length information included in the record itself. 172 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 173 only. There is no dedicated "CID update" message that allows new 174 CIDs to be established mid-session, because DTLS 1.2 in general does 175 not allow TLS 1.3-style post-handshake messages that do not 176 themselves begin other handshakes. When a DTLS session is resumed or 177 renegotiated, the "connection_id" extension is negotiated afresh. 179 If DTLS peers have not negotiated the use of CIDs, or a zero-length 180 CID has been advertised for a given direction, then the RFC 181 6347-defined record format and content type MUST be used to send in 182 the indicated direction(s). 184 If DTLS peers have negotiated the use of a non-zero-length CID for a 185 given direction, then once encryption is enabled they MUST send with 186 the record format defined in {{dtls-ciphertext} with the new MAC 187 computation defined in Section 5 and the content type tls12_cid. 188 Plaintext payloads never use the new record type and the CID content 189 type. 191 When receiving, if the tls12_cid content type is set, then the CID is 192 used to look up the connection and the security association. If the 193 tls12_cid content type is not set, then the connection and security 194 association is looked up by the 5-tuple and a check MUST be made to 195 determine whether a non-zero length CID is expected. If a non-zero- 196 length CID is expected for the retrieved association, then the 197 datagram MUST be treated as invalid, as described in Section 4.1.2.1 198 of [RFC6347]. 200 When receiving a datagram with the tls12_cid content type, the new 201 MAC computation defined in Section 5 MUST be used. When receiving a 202 datagram with the RFC 6347-defined record format the MAC calculation 203 defined in Section 4.1.2 of [RFC6347] MUST be used. 205 4. Record Layer Extensions 207 This specification defines the DTLS 1.2 record layer format and 208 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 210 To allow a receiver to determine whether a record has a CID or not, 211 connections which have negotiated this extension use a distinguished 212 record type tls12_cid(TBD2). Use of this content type has the 213 following three implications: 215 * The CID field is present and contains one or more bytes. 217 * The MAC calculation follows the process described in Section 5. 219 * The true content type is inside the encryption envelope, as 220 described below. 222 Plaintext records are not impacted by this extension. Hence, the 223 format of the DTLSPlaintext structure is left unchanged, as shown in 224 Figure 1. 226 struct { 227 ContentType type; 228 ProtocolVersion version; 229 uint16 epoch; 230 uint48 sequence_number; 231 uint16 length; 232 opaque fragment[DTLSPlaintext.length]; 233 } DTLSPlaintext; 235 Figure 1: DTLS 1.2 Plaintext Record Payload. 237 When CIDs are being used, the content to be sent is first wrapped 238 along with its content type and optional padding into a 239 DTLSInnerPlaintext structure. This newly introduced structure is 240 shown in Figure 2. The DTLSInnerPlaintext byte sequence is then 241 encrypted. To create the DTLSCiphertext structure shown in Figure 3 242 the CID is added. 244 struct { 245 opaque content[length]; 246 ContentType real_type; 247 uint8 zeros[length_of_padding]; 248 } DTLSInnerPlaintext; 250 Figure 2: New DTLSInnerPlaintext Payload Structure. 252 content Corresponds to the fragment of a given length. 254 real_type The content type describing the cleartext payload. 256 zeros An arbitrary-length run of zero-valued bytes may appear in the 257 cleartext after the type field. This provides an opportunity for 258 senders to pad any DTLS record by a chosen amount as long as the 259 total stays within record size limits. See Section 5.4 of 260 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 261 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 263 struct { 264 ContentType outer_type = tls12_cid; 265 ProtocolVersion version; 266 uint16 epoch; 267 uint48 sequence_number; 268 opaque cid[cid_length]; // New field 269 uint16 length; 270 opaque enc_content[DTLSCiphertext.length]; 271 } DTLSCiphertext; 273 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 275 outer_type The outer content type of a DTLSCiphertext record 276 carrying a CID is always set to tls12_cid(TBD2). The real content 277 type of the record is found in DTLSInnerPlaintext.real_type after 278 decryption. 280 cid The CID value, cid_length bytes long, as agreed at the time the 281 extension has been negotiated. Recall that (as discussed 282 previously) each peer chooses the CID value it will receive and 283 use to identify the connection, so an implementation can choose to 284 always receive CIDs of a fixed length. If, however, an 285 implementation chooses to receive different lengths of CID, the 286 assigned CID values must be self-delineating since there is no 287 other mechanism available to determine what connection (and thus, 288 what CID length) is in use. 290 enc_content The encrypted form of the serialized DTLSInnerPlaintext 291 structure. 293 All other fields are as defined in RFC 6347. 295 5. Record Payload Protection 297 Several types of ciphers have been defined for use with TLS and DTLS 298 and the MAC calculations for those ciphers differ slightly. 300 This specification modifies the MAC calculation as defined in 301 [RFC6347] and [RFC7366], as well as the definition of the additional 302 data used with AEAD ciphers provided in [RFC6347], for records with 303 content type tls12_cid. The modified algorithm MUST NOT be applied 304 to records that do not carry a CID, i.e., records with content type 305 other than tls12_cid. 307 The following fields are defined in this document; all other fields 308 are as defined in the cited documents. 310 cid Value of the negotiated CID (variable length). 312 cid_length 1 byte field indicating the length of the negotiated CID. 314 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 315 DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 316 2^14. 318 seq_num_placeholder 8 bytes of 0xff 320 Note "+" denotes concatenation. 322 5.1. Block Ciphers 324 The following MAC algorithm applies to block ciphers that do not use 325 the Encrypt-then-MAC processing described in [RFC7366]. 327 MAC(MAC_write_key, 328 seq_num_placeholder + 329 tls12_cid + 330 cid_length + 331 tls12_cid + 332 DTLSCiphertext.version + 333 epoch + 334 sequence_number + 335 cid + 336 length_of_DTLSInnerPlaintext + 337 DTLSInnerPlaintext.content + 338 DTLSInnerPlaintext.real_type + 339 DTLSInnerPlaintext.zeros 340 ); 342 The rationale behind this construction is to separate the MAC input 343 for DTLS without the connection ID from the MAC input with the 344 connection ID. The former always consists of a sequence number 345 followed by some other content type than tls12_cid; the latter always 346 consists of the seq_num_placeholder followed by tls12_cid. Although 347 2^64-1 is potentially a valid sequence number, tls12_cid will never 348 be a valid content type when the connection ID is not in use. In 349 addition, the epoch and sequence_number are now fed into the MAC in 350 the same order as they appear on the wire. 352 5.2. Block Ciphers with Encrypt-then-MAC processing 354 The following MAC algorithm applies to block ciphers that use the 355 with Encrypt-then-MAC processing described in [RFC7366]. 357 MAC(MAC_write_key, 358 seq_num_placeholder + 359 tls12_cid + 360 cid_length + 361 tls12_cid + 362 DTLSCiphertext.version + 363 epoch + 364 sequence_number + 365 cid + 366 DTLSCiphertext.length + 367 IV + 368 ENC(content + padding + padding_length)); 370 5.3. AEAD Ciphers 372 For ciphers utilizing authenticated encryption with additional data 373 the following modification is made to the additional data 374 calculation. 376 additional_data = seq_num_placeholder + 377 tls12_cid + 378 cid_length + 379 tls12_cid + 380 DTLSCiphertext.version + 381 epoch + 382 sequence_number + 383 cid + 384 length_of_DTLSInnerPlaintext; 386 6. Peer Address Update 388 When a record with a CID is received that has a source address 389 different than the one currently associated with the DTLS connection, 390 the receiver MUST NOT replace the address it uses for sending records 391 to its peer with the source address specified in the received 392 datagram unless the following three conditions are met: 394 * The received datagram has been cryptographically verified using 395 the DTLS record layer processing procedures. 397 * The received datagram is "newer" (in terms of both epoch and 398 sequence number) than the newest datagram received. Reordered 399 datagrams that are sent prior to a change in a peer address might 400 otherwise cause a valid address change to be reverted. This also 401 limits the ability of an attacker to use replayed datagrams to 402 force a spurious address change, which could result in denial of 403 service. An attacker might be able to succeed in changing a peer 404 address if they are able to rewrite source addresses and if 405 replayed packets are able to arrive before any original. 407 * There is a strategy for ensuring that the new peer address is able 408 to receive and process DTLS records. No such strategy is defined 409 in this specification. 411 The conditions above are necessary to protect against attacks that 412 use datagrams with spoofed addresses or replayed datagrams to trigger 413 attacks. Note that there is no requirement for use of the anti- 414 replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2. Both 415 solutions, the "anti-replay window" or "newer" algorithm, will 416 prevent address updates from replay attacks while the latter will 417 only apply to peer address updates and the former applies to any 418 application layer traffic. 420 Note that datagrams that pass the DTLS cryptographic verification 421 procedures but do not trigger a change of peer address are still 422 valid DTLS records and are still to be passed to the application. 424 Application protocols that implement protection against these attacks 425 depend on being aware of changes in peer addresses so that they can 426 engage the necessary mechanisms. When delivered such an event, an 427 application layer-specific address validation mechanism can be 428 triggered, for example one that is based on successful exchange of a 429 minimal amount of ping-pong traffic with the peer. Alternatively, an 430 DTLS-specific mechanism may be used, as described in 431 [I-D.tschofenig-tls-dtls-rrc]. 433 DTLS implementations MUST silently discard records with bad MACs or 434 that are otherwise invalid. 436 7. Examples 438 Figure 4 shows an example exchange where a CID is used uni- 439 directionally from the client to the server. To indicate that a 440 zero-length CID is present in the "connection_id" extension we use 441 the notation 'connection_id=empty'. 443 Client Server 444 ------ ------ 446 ClientHello --------> 447 (connection_id=empty) 449 <-------- HelloVerifyRequest 450 (cookie) 452 ClientHello --------> 453 (connection_id=empty) 454 (cookie) 456 ServerHello 457 (connection_id=100) 458 Certificate 459 ServerKeyExchange 460 CertificateRequest 461 <-------- ServerHelloDone 463 Certificate 464 ClientKeyExchange 465 CertificateVerify 466 [ChangeCipherSpec] 467 Finished --------> 468 470 [ChangeCipherSpec] 471 <-------- Finished 473 Application Data ========> 474 476 <======== Application Data 478 Legend: 480 <...> indicates that a connection id is used in the record layer 481 (...) indicates an extension 482 [...] indicates a payload other than a handshake message 484 Figure 4: Example DTLS 1.2 Exchange with CID 486 Note: In the example exchange the CID is included in the record layer 487 once encryption is enabled. In DTLS 1.2 only one handshake message 488 is encrypted, namely the Finished message. Since the example shows 489 how to use the CID for payloads sent from the client to the server, 490 only the record layer payloads containing the Finished message or 491 application data include a CID. 493 8. Privacy Considerations 495 The CID replaces the previously used 5-tuple and, as such, introduces 496 an identifier that remains persistent during the lifetime of a DTLS 497 connection. Every identifier introduces the risk of linkability, as 498 explained in [RFC6973]. 500 An on-path adversary observing the DTLS protocol exchanges between 501 the DTLS client and the DTLS server is able to link the observed 502 payloads to all subsequent payloads carrying the same ID pair (for 503 bi-directional communication). Without multi-homing or mobility, the 504 use of the CID exposes the same information as the 5-tuple. 506 With multi-homing, a passive attacker is able to correlate the 507 communication interaction over the two paths. The lack of a CID 508 update mechanism in DTLS 1.2 makes this extension unsuitable for 509 mobility scenarios where correlation must be considered. Deployments 510 that use DTLS in multi-homing environments and are concerned about 511 these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to 512 DTLS 1.3 where a CID update mechanism is provided and sequence number 513 encryption is available. 515 The specification introduces record padding for the CID-enhanced 516 record layer, which is a privacy feature not available with the 517 original DTLS 1.2 specification. Padding allows to inflate the size 518 of the ciphertext making traffic analysis more difficult. More 519 details about record padding can be found in Section 5.4 and 520 Appendix E.3 of RFC 8446. 522 Finally, endpoints can use the CID to attach arbitrary per-connection 523 metadata to each record they receive on a given connection. This may 524 be used as a mechanism to communicate per-connection information to 525 on-path observers. There is no straightforward way to address this 526 concern with CIDs that contain arbitrary values. Implementations 527 concerned about this aspect SHOULD refuse to use CIDs. 529 9. Security Considerations 531 An on-path adversary can create reflection attacks against third 532 parties because a DTLS peer has no means to distinguish a genuine 533 address update event (for example, due to a NAT rebinding) from one 534 that is malicious. This attack is of particular concern when the 535 request is small and the response large. See Section 6 for more on 536 address updates. 538 Additionally, an attacker able to observe the data traffic exchanged 539 between two DTLS peers is able to replay datagrams with modified IP 540 address/port numbers. 542 The topic of peer address updates is discussed in Section 6. 544 10. IANA Considerations 546 This document requests three actions by IANA. 548 10.1. Extra Column to TLS ExtensionType Values Registry 550 IANA is requested to add an extra column named "DTLS-Only" to the 551 "TLS ExtensionType Values" registry to indicate whether an extension 552 is only applicable to DTLS and to include this document as an 553 additional reference for the registry. 555 10.2. Entry to the TLS ExtensionType Values Registry 557 IANA is requested to allocate an entry to the existing "TLS 558 ExtensionType Values" registry, for connection_id(TBD1) as described 559 in the table below. Although the value 53 has been allocated by 560 early allocation for a previous version of this document, it is 561 incompatible with this document. Once this document is approved for 562 publication, the early allocation will be deprecated in favor of this 563 assignment. 565 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 566 -------------------------------------------------------------------- 567 TBD1 connection_id CH, SH Y N [[This doc]] 569 Note: The value "N" in the Recommended column is set because this 570 extension is intended only for specific use cases. This document 571 describes the behavior of this extension for DTLS 1.2 only; it is not 572 applicable to TLS, and its usage for DTLS 1.3 is described in 573 [I-D.ietf-tls-dtls13]. 575 10.3. Entry to the TLS ContentType Registry 577 IANA is requested to allocate tls12_cid(TBD2) in the "TLS 578 ContentType" registry. The tls12_cid ContentType is only applicable 579 to DTLS 1.2. 581 11. References 583 11.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 591 (TLS) Protocol Version 1.2", RFC 5246, 592 DOI 10.17487/RFC5246, August 2008, 593 . 595 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 596 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 597 January 2012, . 599 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 600 Security (TLS) and Datagram Transport Layer Security 601 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 602 . 604 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 605 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 606 May 2017, . 608 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 609 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 610 . 612 11.2. Informative References 614 [I-D.ietf-tls-dtls13] 615 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 616 Datagram Transport Layer Security (DTLS) Protocol Version 617 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 618 dtls13-40, 20 January 2021, . 621 [I-D.tschofenig-tls-dtls-rrc] 622 Fossati, T. and H. Tschofenig, "Return Routability Check 623 for DTLS 1.2 and DTLS 1.3", Work in Progress, Internet- 624 Draft, draft-tschofenig-tls-dtls-rrc-01, 2 March 2020, 625 . 628 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 629 Morris, J., Hansen, M., and R. Smith, "Privacy 630 Considerations for Internet Protocols", RFC 6973, 631 DOI 10.17487/RFC6973, July 2013, 632 . 634 Appendix A. History 636 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 638 draft-ietf-tls-dtls-connection-id-10 640 * Clarify privacy impact. 642 * Have security considerations point to Section 6. 644 draft-ietf-tls-dtls-connection-id-09 646 * Changed MAC/additional data calculation. 648 * Disallow sending MAC failure fatal alerts to non-validated peers. 650 * Incorporated editorial review comments by Ben Kaduk. 652 draft-ietf-tls-dtls-connection-id-08 654 * RRC draft moved from normative to informative. 656 draft-ietf-tls-dtls-connection-id-07 658 * Wording changes in the security and privacy consideration and the 659 peer address update sections. 661 draft-ietf-tls-dtls-connection-id-06 663 * Updated IANA considerations 665 * Enhanced security consideration section to describe a potential 666 man-in-the-middle attack concerning address validation. 668 draft-ietf-tls-dtls-connection-id-05 670 * Restructed Section 5 "Record Payload Protection" 672 draft-ietf-tls-dtls-connection-id-04 674 * Editorial simplifications to the 'Record Layer Extensions' and the 675 'Record Payload Protection' sections. 677 * Added MAC calculations for block ciphers with and without Encrypt- 678 then-MAC processing. 680 draft-ietf-tls-dtls-connection-id-03 681 * Updated list of contributors 683 * Updated list of contributors and acknowledgements 685 * Updated example 687 * Changed record layer design 689 * Changed record payload protection 691 * Updated introduction and security consideration section 693 * Author- and affiliation changes 695 draft-ietf-tls-dtls-connection-id-02 697 * Move to internal content types a la DTLS 1.3. 699 draft-ietf-tls-dtls-connection-id-01 701 * Remove 1.3 based on the WG consensus at IETF 101 703 draft-ietf-tls-dtls-connection-id-00 705 * Initial working group version (containing a solution for DTLS 1.2 706 and 1.3) 708 draft-rescorla-tls-dtls-connection-id-00 710 * Initial version 712 Appendix B. Working Group Information 714 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 716 The discussion list for the IETF TLS working group is located at the 717 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 718 the group and information on how to subscribe to the list is at 719 https://www1.ietf.org/mailman/listinfo/tls 720 (https://www1.ietf.org/mailman/listinfo/tls) 722 Archives of the list can be found at: https://www.ietf.org/mail- 723 archive/web/tls/current/index.html (https://www.ietf.org/mail- 724 archive/web/tls/current/index.html) 726 Appendix C. Contributors 728 Many people have contributed to this specification and we would like 729 to thank the following individuals for their contributions: 731 * Yin Xinxing 732 Huawei 733 yinxinxing@huawei.com 735 * Nikos Mavrogiannopoulos 736 RedHat 737 nmav@redhat.com 739 * Tobias Gondrom 740 tobias.gondrom@gondrom.org 742 Additionally, we would like to thank the Connection ID task force 743 team members: 745 * Martin Thomson (Mozilla) 747 * Christian Huitema (Private Octopus Inc.) 749 * Jana Iyengar (Google) 751 * Daniel Kahn Gillmor (ACLU) 753 * Patrick McManus (Mozilla) 755 * Ian Swett (Google) 757 * Mark Nottingham (Fastly) 759 The task force team discussed various design ideas, including 760 cryptographically generated session ids using hash chains and public 761 key encryption, but dismissed them due to their inefficiency. The 762 approach described in this specification is the simplest possible 763 design that works given the limitations of DTLS 1.2. DTLS 1.3 764 provides better privacy features and developers are encouraged to 765 switch to the new version of DTLS. 767 Appendix D. Acknowledgements 769 We would like to thank Tom Petch, Ben Kaduk, Sean Turner, and Hanno 770 Becker for their review comments. 772 Finally, we want to thank the IETF TLS working group chairs, Chris 773 Wood, Joseph Salowey, and Sean Turner, for their patience, support 774 and feedback. 776 Authors' Addresses 778 Eric Rescorla (editor) 779 RTFM, Inc. 781 Email: ekr@rtfm.com 783 Hannes Tschofenig (editor) 784 Arm Limited 786 Email: hannes.tschofenig@arm.com 788 Thomas Fossati 789 Arm Limited 791 Email: thomas.fossati@arm.com 793 Achim Kraus 794 Bosch.IO GmbH 796 Email: achim.kraus@bosch.io