idnits 2.17.1 draft-ietf-tls-dtls-connection-id-13.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 (22 June 2021) is 1037 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 481, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-tls-dtls-rrc-00 Summary: 1 error (**), 0 flaws (~~), 3 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: 24 December 2021 Arm Limited 7 A. Kraus 8 Bosch.IO GmbH 9 22 June 2021 11 Connection Identifiers for DTLS 1.2 12 draft-ietf-tls-dtls-connection-id-13 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 The new ciphertext record format with CID also provides content type 28 encryption and record-layer padding. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 24 December 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 77 3. The "connection_id" Extension . . . . . . . . . . . . . . . . 4 78 4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5 79 5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7 80 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 81 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 8 82 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 9 83 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 9 84 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Extra Column to TLS ExtensionType Values Registry . . . 13 89 10.2. Entry to the TLS ExtensionType Values Registry . . . . . 13 90 10.3. Entry to the TLS ContentType Registry . . . . . . . . . 13 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 11.2. Informative References . . . . . . . . . . . . . . . . . 14 94 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 15 95 Appendix B. Working Group Information . . . . . . . . . . . . . 17 96 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 17 97 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 The Datagram Transport Layer Security (DTLS) [RFC6347] protocol was 103 designed for securing connection-less transports, like UDP. DTLS, 104 like TLS, starts with a handshake, which can be computationally 105 demanding (particularly when public key cryptography is used). After 106 a successful handshake, symmetric key cryptography is used to apply 107 data origin authentication, integrity and confidentiality protection. 108 This two-step approach allows endpoints to amortize the cost of the 109 initial handshake across subsequent application data protection. 110 Ideally, the second phase where application data is protected lasts 111 over a long period of time since the established keys will only need 112 to be updated once the key lifetime expires. 114 In DTLS as specified in RFC 6347, the IP address and port of the peer 115 are used to identify the DTLS association. Unfortunately, in some 116 cases, such as NAT rebinding, these values are insufficient. This is 117 a particular issue in the Internet of Things when devices enter 118 extended sleep periods to increase their battery lifetime. The NAT 119 rebinding leads to connection failure, with the resulting cost of a 120 new handshake. 122 This document defines an extension to DTLS 1.2 to add a Connection ID 123 (CID) to the DTLS record layer. The presence of the CID is 124 negotiated via a DTLS extension. 126 Adding a CID to the ciphertext record format presents an opportunity 127 to make other changes to the record format. In keeping with the best 128 practices established by TLS 1.3, the type of the record is 129 encrypted, and a mechanism provided for adding padding to obfuscate 130 the plaintext length. 132 2. Conventions and Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 This document assumes familiarity with DTLS 1.2 [RFC6347]. The 141 presentation language used in this document is described in Section 3 142 of [RFC8446]. 144 3. The "connection_id" Extension 146 This document defines the "connection_id" extension, which is used in 147 ClientHello and ServerHello messages. 149 The extension type is specified as follows. 151 enum { 152 connection_id(TBD1), (65535) 153 } ExtensionType; 155 The extension_data field of this extension, when included in the 156 ClientHello, MUST contain the ConnectionId structure. This structure 157 contains the CID value the client wishes the server to use when 158 sending messages to the client. A zero-length CID value indicates 159 that the client is prepared to send using a CID but does not wish the 160 server to use one when sending. 162 struct { 163 opaque cid<0..2^8-1>; 164 } ConnectionId; 166 A server willing to use CIDs will respond with a "connection_id" 167 extension in the ServerHello, containing the CID it wishes the client 168 to use when sending messages towards it. A zero-length value 169 indicates that the server will send using the client's CID but does 170 not wish the client to include a CID when sending. 172 Because each party sends the value in the "connection_id" extension 173 it wants to receive as a CID in encrypted records, it is possible for 174 an endpoint to use a deployment-specific constant length for such 175 connection identifiers. This can in turn ease parsing and connection 176 lookup, for example by having the length in question be a compile- 177 time constant. Such implementations MUST still be able to send CIDs 178 of different length to other parties. Since the CID length 179 information is not included in the record itself, implementations 180 that want to use variable-length CIDs are responsible for 181 constructing the CID in such a way that its length can be determined 182 on reception. 184 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 185 only. There is no dedicated "CID update" message that allows new 186 CIDs to be established mid-session, because DTLS 1.2 in general does 187 not allow TLS 1.3-style post-handshake messages that do not 188 themselves begin other handshakes. When a DTLS session is resumed or 189 renegotiated, the "connection_id" extension is negotiated afresh. 191 If DTLS peers have not negotiated the use of CIDs, or a zero-length 192 CID has been advertised for a given direction, then the RFC 193 6347-defined record format and content type MUST be used to send in 194 the indicated direction(s). 196 If DTLS peers have negotiated the use of a non-zero-length CID for a 197 given direction, then once encryption is enabled they MUST send with 198 the record format defined in Figure 3 with the new MAC computation 199 defined in Section 5 and the content type tls12_cid. Plaintext 200 payloads never use the new record format or the CID content type. 202 When receiving, if the tls12_cid content type is set, then the CID is 203 used to look up the connection and the security association. If the 204 tls12_cid content type is not set, then the connection and security 205 association is looked up by the 5-tuple and a check MUST be made to 206 determine whether a non-zero length CID is expected. If a non-zero- 207 length CID is expected for the retrieved association, then the 208 datagram MUST be treated as invalid, as described in Section 4.1.2.1 209 of [RFC6347]. 211 When receiving a datagram with the tls12_cid content type, the new 212 MAC computation defined in Section 5 MUST be used. When receiving a 213 datagram with the RFC 6347-defined record format, the MAC calculation 214 defined in Section 4.1.2 of [RFC6347] MUST be used. 216 4. Record Layer Extensions 218 This specification defines the DTLS 1.2 record layer format and 219 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 221 To allow a receiver to determine whether a record has a CID or not, 222 connections which have negotiated this extension use a distinguished 223 record type tls12_cid(TBD2). Use of this content type has the 224 following three implications: 226 * The CID field is present and contains one or more bytes. 228 * The MAC calculation follows the process described in Section 5. 230 * The real content type is inside the encryption envelope, as 231 described below. 233 Plaintext records are not impacted by this extension. Hence, the 234 format of the DTLSPlaintext structure is left unchanged, as shown in 235 Figure 1. 237 struct { 238 ContentType type; 239 ProtocolVersion version; 240 uint16 epoch; 241 uint48 sequence_number; 242 uint16 length; 243 opaque fragment[DTLSPlaintext.length]; 244 } DTLSPlaintext; 246 Figure 1: DTLS 1.2 Plaintext Record Payload. 248 When CIDs are being used, the content to be sent is first wrapped 249 along with its content type and optional padding into a 250 DTLSInnerPlaintext structure. This newly introduced structure is 251 shown in Figure 2. 253 struct { 254 opaque content[length]; 255 ContentType real_type; 256 uint8 zeros[length_of_padding]; 257 } DTLSInnerPlaintext; 259 Figure 2: New DTLSInnerPlaintext Payload Structure. 261 content Corresponds to the fragment of a given length. 263 real_type The content type describing the cleartext payload. 265 zeros An arbitrary-length run of zero-valued bytes may appear in the 266 cleartext after the type field. This provides an opportunity for 267 senders to pad any DTLS record by a chosen amount as long as the 268 total stays within record size limits. See Section 5.4 of 269 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 270 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 272 The DTLSInnerPlaintext byte sequence is then encrypted. To create 273 the DTLSCiphertext structure shown in Figure 3 the CID is added. 275 struct { 276 ContentType outer_type = tls12_cid; 277 ProtocolVersion version; 278 uint16 epoch; 279 uint48 sequence_number; 280 opaque cid[cid_length]; // New field 281 uint16 length; 282 opaque enc_content[DTLSCiphertext.length]; 283 } DTLSCiphertext; 284 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 286 outer_type The outer content type of a DTLSCiphertext record 287 carrying a CID is always set to tls12_cid(TBD2). The real content 288 type of the record is found in DTLSInnerPlaintext.real_type after 289 decryption. 291 cid The CID value, cid_length bytes long, as agreed at the time the 292 extension has been negotiated. Recall that (as discussed 293 previously) each peer chooses the CID value it will receive and 294 use to identify the connection, so an implementation can choose to 295 always receive CIDs of a fixed length. If, however, an 296 implementation chooses to receive different lengths of CID, the 297 assigned CID values must be self-delineating since there is no 298 other mechanism available to determine what connection (and thus, 299 what CID length) is in use. 301 enc_content The encrypted form of the serialized DTLSInnerPlaintext 302 structure. 304 All other fields are as defined in RFC 6347. 306 5. Record Payload Protection 308 Several types of ciphers have been defined for use with TLS and DTLS 309 and the MAC calculations for those ciphers differ slightly. 311 This specification modifies the MAC calculation as defined in 312 [RFC6347] and [RFC7366], as well as the definition of the additional 313 data used with AEAD ciphers provided in [RFC6347], for records with 314 content type tls12_cid. The modified algorithm MUST NOT be applied 315 to records that do not carry a CID, i.e., records with content type 316 other than tls12_cid. 318 The following fields are defined in this document; all other fields 319 are as defined in the cited documents. 321 cid Value of the negotiated CID (variable length). 323 cid_length 1 byte field indicating the length of the negotiated CID. 325 length_of_DTLSInnerPlaintext The length (in bytes) of the serialized 326 DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 327 2^14. 329 seq_num_placeholder 8 bytes of 0xff 331 Note "+" denotes concatenation. 333 5.1. Block Ciphers 335 The following MAC algorithm applies to block ciphers that do not use 336 the Encrypt-then-MAC processing described in [RFC7366]. 338 MAC(MAC_write_key, 339 seq_num_placeholder + 340 tls12_cid + 341 cid_length + 342 tls12_cid + 343 DTLSCiphertext.version + 344 epoch + 345 sequence_number + 346 cid + 347 length_of_DTLSInnerPlaintext + 348 DTLSInnerPlaintext.content + 349 DTLSInnerPlaintext.real_type + 350 DTLSInnerPlaintext.zeros 351 ); 353 The rationale behind this construction is to separate the MAC input 354 for DTLS without the connection ID from the MAC input with the 355 connection ID. The former always consists of a sequence number 356 followed by some other content type than tls12_cid; the latter always 357 consists of the seq_num_placeholder followed by tls12_cid. Although 358 2^64-1 is potentially a valid sequence number, tls12_cid will never 359 be a valid content type when the connection ID is not in use. In 360 addition, the epoch and sequence_number are now fed into the MAC in 361 the same order as they appear on the wire. 363 5.2. Block Ciphers with Encrypt-then-MAC processing 365 The following MAC algorithm applies to block ciphers that use the 366 Encrypt-then-MAC processing described in [RFC7366]. 368 MAC(MAC_write_key, 369 seq_num_placeholder + 370 tls12_cid + 371 cid_length + 372 tls12_cid + 373 DTLSCiphertext.version + 374 epoch + 375 sequence_number + 376 cid + 377 DTLSCiphertext.length + 378 IV + 379 ENC(content + padding + padding_length)); 381 5.3. AEAD Ciphers 383 For ciphers utilizing authenticated encryption with additional data 384 the following modification is made to the additional data 385 calculation. 387 additional_data = seq_num_placeholder + 388 tls12_cid + 389 cid_length + 390 tls12_cid + 391 DTLSCiphertext.version + 392 epoch + 393 sequence_number + 394 cid + 395 length_of_DTLSInnerPlaintext; 397 6. Peer Address Update 399 When a record with a CID is received that has a source address 400 different from the one currently associated with the DTLS connection, 401 the receiver MUST NOT replace the address it uses for sending records 402 to its peer with the source address specified in the received 403 datagram, unless the following three conditions are met: 405 * The received datagram has been cryptographically verified using 406 the DTLS record layer processing procedures. 408 * The received datagram is "newer" (in terms of both epoch and 409 sequence number) than the newest datagram received. Reordered 410 datagrams that are sent prior to a change in a peer address might 411 otherwise cause a valid address change to be reverted. This also 412 limits the ability of an attacker to use replayed datagrams to 413 force a spurious address change, which could result in denial of 414 service. An attacker might be able to succeed in changing a peer 415 address if they are able to rewrite source addresses and if 416 replayed packets are able to arrive before any original. 418 * There is a strategy for ensuring that the new peer address is able 419 to receive and process DTLS records. No strategy is mandated by 420 this specification but see note (*) below. 422 The conditions above are necessary to protect against attacks that 423 use datagrams with spoofed addresses or replayed datagrams to trigger 424 attacks. Note that there is no requirement for use of the anti- 425 replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2. Both 426 solutions, the "anti-replay window" or "newer" algorithm, will 427 prevent address updates from replay attacks while the latter will 428 only apply to peer address updates and the former applies to any 429 application layer traffic. 431 Note that datagrams that pass the DTLS cryptographic verification 432 procedures but do not trigger a change of peer address are still 433 valid DTLS records and are still to be passed to the application. 435 (*) Note: Application protocols that implement protection against 436 spoofed addresses depend on being aware of changes in peer addresses 437 so that they can engage the necessary mechanisms. When delivered 438 such an event, an application layer-specific address validation 439 mechanism can be triggered, for example one that is based on 440 successful exchange of a minimal amount of ping-pong traffic with the 441 peer. Alternatively, an DTLS-specific mechanism may be used, as 442 described in [I-D.ietf-tls-dtls-rrc]. 444 DTLS implementations MUST silently discard records with bad MACs or 445 that are otherwise invalid. 447 7. Examples 449 Figure 4 shows an example exchange where a CID is used uni- 450 directionally from the client to the server. To indicate that a 451 zero-length CID is present in the "connection_id" extension we use 452 the notation 'connection_id=empty'. 454 Client Server 455 ------ ------ 457 ClientHello --------> 458 (connection_id=empty) 460 <-------- HelloVerifyRequest 461 (cookie) 463 ClientHello --------> 464 (connection_id=empty) 465 (cookie) 467 ServerHello 468 (connection_id=100) 469 Certificate 470 ServerKeyExchange 471 CertificateRequest 472 <-------- ServerHelloDone 474 Certificate 475 ClientKeyExchange 476 CertificateVerify 477 [ChangeCipherSpec] 478 Finished --------> 479 481 [ChangeCipherSpec] 482 <-------- Finished 484 Application Data ========> 485 487 <======== Application Data 489 Legend: 491 <...> indicates that a connection id is used in the record layer 492 (...) indicates an extension 493 [...] indicates a payload other than a handshake message 495 Figure 4: Example DTLS 1.2 Exchange with CID 497 Note: In the example exchange the CID is included in the record layer 498 once encryption is enabled. In DTLS 1.2 only one handshake message 499 is encrypted, namely the Finished message. Since the example shows 500 how to use the CID for payloads sent from the client to the server, 501 only the record layer payloads containing the Finished message or 502 application data include a CID. 504 8. Privacy Considerations 506 The CID replaces the previously used 5-tuple and, as such, introduces 507 an identifier that remains persistent during the lifetime of a DTLS 508 connection. Every identifier introduces the risk of linkability, as 509 explained in [RFC6973]. 511 An on-path adversary observing the DTLS protocol exchanges between 512 the DTLS client and the DTLS server is able to link the observed 513 payloads to all subsequent payloads carrying the same ID pair (for 514 bi-directional communication). Without multi-homing or mobility, the 515 use of the CID exposes the same information as the 5-tuple. 517 With multi-homing, a passive attacker is able to correlate the 518 communication interaction over the two paths. The lack of a CID 519 update mechanism in DTLS 1.2 makes this extension unsuitable for 520 mobility scenarios where correlation must be considered. Deployments 521 that use DTLS in multi-homing environments and are concerned about 522 these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to 523 DTLS 1.3 where a CID update mechanism is provided and sequence number 524 encryption is available. 526 The specification introduces record padding for the CID-enhanced 527 record layer, which is a privacy feature not available with the 528 original DTLS 1.2 specification. Padding allows to inflate the size 529 of the ciphertext making traffic analysis more difficult. More 530 details about record padding can be found in Section 5.4 and 531 Appendix E.3 of RFC 8446. 533 Finally, endpoints can use the CID to attach arbitrary per-connection 534 metadata to each record they receive on a given connection. This may 535 be used as a mechanism to communicate per-connection information to 536 on-path observers. There is no straightforward way to address this 537 concern with CIDs that contain arbitrary values. Implementations 538 concerned about this aspect SHOULD refuse to use CIDs. 540 9. Security Considerations 542 An on-path adversary can create reflection attacks against third 543 parties because a DTLS peer has no means to distinguish a genuine 544 address update event (for example, due to a NAT rebinding) from one 545 that is malicious. This attack is of particular concern when the 546 request is small and the response large. See Section 6 for more on 547 address updates. 549 Additionally, an attacker able to observe the data traffic exchanged 550 between two DTLS peers is able to replay datagrams with modified IP 551 address/port numbers. 553 The topic of peer address updates is discussed in Section 6. 555 10. IANA Considerations 557 This document requests three actions from IANA. 559 10.1. Extra Column to TLS ExtensionType Values Registry 561 IANA is requested to add an extra column named "DTLS-Only" to the 562 "TLS ExtensionType Values" registry to indicate whether an extension 563 is only applicable to DTLS and to include this document as an 564 additional reference for the registry. 566 10.2. Entry to the TLS ExtensionType Values Registry 568 IANA is requested to allocate an entry to the existing "TLS 569 ExtensionType Values" registry, for connection_id(TBD1) as described 570 in the table below. Although the value 53 has been allocated by 571 early allocation for a previous version of this document, it is 572 incompatible with this document. Once this document is approved for 573 publication, the early allocation will be deprecated in favor of this 574 assignment. 576 Value Extension Name TLS 1.3 DTLS-Only Recommended Reference 577 -------------------------------------------------------------------- 578 TBD1 connection_id CH, SH Y N [[This doc]] 580 A new column "DTLS-Only" is added to the registry. The valid entries 581 are "Y" if the extension is only applicable to DTLS, "N" otherwise. 582 All the pre-existing entries are given the value "N". 584 Note: The value "N" in the Recommended column is set because this 585 extension is intended only for specific use cases. This document 586 describes the behavior of this extension for DTLS 1.2 only; it is not 587 applicable to TLS, and its usage for DTLS 1.3 is described in 588 [I-D.ietf-tls-dtls13]. 590 10.3. Entry to the TLS ContentType Registry 592 IANA is requested to allocate tls12_cid(TBD2) in the "TLS 593 ContentType" registry. The tls12_cid ContentType is only applicable 594 to DTLS 1.2. 596 11. References 597 11.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, 602 . 604 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 605 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 606 January 2012, . 608 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 609 Security (TLS) and Datagram Transport Layer Security 610 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 611 . 613 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 614 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 615 May 2017, . 617 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 618 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 619 . 621 11.2. Informative References 623 [I-D.ietf-tls-dtls-rrc] 624 Tschofenig, H. and T. Fossati, "Return Routability Check 625 for DTLS 1.2 and DTLS 1.3", Work in Progress, Internet- 626 Draft, draft-ietf-tls-dtls-rrc-00, 9 June 2021, 627 . 630 [I-D.ietf-tls-dtls13] 631 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 632 Datagram Transport Layer Security (DTLS) Protocol Version 633 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 634 dtls13-43, 30 April 2021, 635 . 638 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 639 Morris, J., Hansen, M., and R. Smith, "Privacy 640 Considerations for Internet Protocols", RFC 6973, 641 DOI 10.17487/RFC6973, July 2013, 642 . 644 Appendix A. History 646 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 648 draft-ietf-tls-dtls-connection-id-12 650 * Improved peer address update text 652 * Editorial improvements 654 * Clarification regarding the use of the TLS ExtensionType Values 655 Registry 657 draft-ietf-tls-dtls-connection-id-11 659 * Enhanced IANA considerations section 661 * Clarifications regarding CID negotiation and zero-length CIDs 663 draft-ietf-tls-dtls-connection-id-10 665 * Clarify privacy impact. 667 * Have security considerations point to Section 6. 669 draft-ietf-tls-dtls-connection-id-09 671 * Changed MAC/additional data calculation. 673 * Disallow sending MAC failure fatal alerts to non-validated peers. 675 * Incorporated editorial review comments by Ben Kaduk. 677 draft-ietf-tls-dtls-connection-id-08 679 * RRC draft moved from normative to informative. 681 draft-ietf-tls-dtls-connection-id-07 683 * Wording changes in the security and privacy consideration and the 684 peer address update sections. 686 draft-ietf-tls-dtls-connection-id-06 688 * Updated IANA considerations 690 * Enhanced security consideration section to describe a potential 691 man-in-the-middle attack concerning address validation. 693 * Restructed Section 5 "Record Payload Protection" 695 draft-ietf-tls-dtls-connection-id-04 697 * Editorial simplifications to the 'Record Layer Extensions' and the 698 'Record Payload Protection' sections. 700 * Added MAC calculations for block ciphers with and without Encrypt- 701 then-MAC processing. 703 draft-ietf-tls-dtls-connection-id-03 705 * Updated list of contributors 707 * Updated list of contributors and acknowledgements 709 * Updated example 711 * Changed record layer design 713 * Changed record payload protection 715 * Updated introduction and security consideration section 717 * Author- and affiliation changes 719 draft-ietf-tls-dtls-connection-id-02 721 * Move to internal content types a la DTLS 1.3. 723 draft-ietf-tls-dtls-connection-id-01 725 * Remove 1.3 based on the WG consensus at IETF 101 727 draft-ietf-tls-dtls-connection-id-00 729 * Initial working group version (containing a solution for DTLS 1.2 730 and 1.3) 732 draft-rescorla-tls-dtls-connection-id-00 734 * Initial version 736 Appendix B. Working Group Information 738 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 740 The discussion list for the IETF TLS working group is located at the 741 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 742 the group and information on how to subscribe to the list is at 743 https://www1.ietf.org/mailman/listinfo/tls 744 (https://www1.ietf.org/mailman/listinfo/tls) 746 Archives of the list can be found at: https://www.ietf.org/mail- 747 archive/web/tls/current/index.html (https://www.ietf.org/mail- 748 archive/web/tls/current/index.html) 750 Appendix C. Contributors 752 Many people have contributed to this specification, and we would like 753 to thank the following individuals for their contributions: 755 * Yin Xinxing 756 Huawei 757 yinxinxing@huawei.com 759 * Nikos Mavrogiannopoulos 760 RedHat 761 nmav@redhat.com 763 * Tobias Gondrom 764 tobias.gondrom@gondrom.org 766 Additionally, we would like to thank the Connection ID task force 767 team members: 769 * Martin Thomson (Mozilla) 771 * Christian Huitema (Private Octopus Inc.) 773 * Jana Iyengar (Google) 775 * Daniel Kahn Gillmor (ACLU) 777 * Patrick McManus (Mozilla) 779 * Ian Swett (Google) 781 * Mark Nottingham (Fastly) 782 The task force team discussed various design ideas, including 783 cryptographically generated session ids using hash chains and public 784 key encryption, but dismissed them due to their inefficiency. The 785 approach described in this specification is the simplest possible 786 design that works given the limitations of DTLS 1.2. DTLS 1.3 787 provides better privacy features and developers are encouraged to 788 switch to the new version of DTLS. 790 Appendix D. Acknowledgements 792 We would like to thank Hanno Becker, Martin Duke, Lars Eggert, Ben 793 Kaduk, Warren Kumari, Francesca Palombini, Tom Petch, John Scudder, 794 Sean Turner, Eric Vyncke, and Robert Wilton for their review 795 comments. 797 Finally, we want to thank the IETF TLS working group chairs, Chris 798 Wood, Joseph Salowey, and Sean Turner, for their patience, support 799 and feedback. 801 Authors' Addresses 803 Eric Rescorla (editor) 804 RTFM, Inc. 806 Email: ekr@rtfm.com 808 Hannes Tschofenig (editor) 809 Arm Limited 811 Email: hannes.tschofenig@arm.com 813 Thomas Fossati 814 Arm Limited 816 Email: thomas.fossati@arm.com 818 Achim Kraus 819 Bosch.IO GmbH 821 Email: achim.kraus@bosch.io