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