idnits 2.17.1 draft-ietf-tls-dtls-connection-id-09.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 (January 18, 2021) is 1195 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 473, but not defined -- Looks like a reference, but probably isn't: '1' on line 691 -- Looks like a reference, but probably isn't: '2' on line 693 -- Looks like a reference, but probably isn't: '3' on line 696 ** 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-39 Summary: 2 errors (**), 0 flaws (~~), 3 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: July 22, 2021 Arm Limited 7 January 18, 2021 9 Connection Identifiers for DTLS 1.2 10 draft-ietf-tls-dtls-connection-id-09 12 Abstract 14 This document specifies the Connection ID (CID) construct for the 15 Datagram Transport Layer Security (DTLS) protocol version 1.2. 17 A CID is an identifier carried in the record layer header that gives 18 the recipient additional information for selecting the appropriate 19 security association. In "classical" DTLS, selecting a security 20 association of an incoming DTLS record is accomplished with the help 21 of the 5-tuple. If the source IP address and/or source port changes 22 during the lifetime of an ongoing DTLS session then the receiver will 23 be unable to locate the correct security context. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 22, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 73 3. The "connection_id" Extension . . . . . . . . . . . . . . . . 3 74 4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5 75 5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7 76 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 77 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 8 78 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 9 80 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . 14 87 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 15 88 Appendix B. Working Group Information . . . . . . . . . . . . . 16 89 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 16 90 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 The Datagram Transport Layer Security (DTLS) [RFC6347] protocol was 96 designed for securing connection-less transports, like UDP. DTLS, 97 like TLS, starts with a handshake, which can be computationally 98 demanding (particularly when public key cryptography is used). After 99 a successful handshake, symmetric key cryptography is used to apply 100 data origin authentication, integrity and confidentiality protection. 101 This two-step approach allows endpoints to amortize the cost of the 102 initial handshake across subsequent application data protection. 103 Ideally, the second phase where application data is protected lasts 104 over a long period of time since the established keys will only need 105 to be updated once the key lifetime expires. 107 In DTLS as specified in RFC 6347, the IP address and port of the peer 108 are used to identify the DTLS association. Unfortunately, in some 109 cases, such as NAT rebinding, these values are insufficient. This is 110 a particular issue in the Internet of Things when devices enter 111 extended sleep periods to increase their battery lifetime. The NAT 112 rebinding leads to connection failure, with the resulting cost of a 113 new handshake. 115 This document defines an extension to DTLS 1.2 to add a CID to the 116 DTLS record layer. The presence of the CID is negotiated via a DTLS 117 extension. 119 2. Conventions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in RFC 124 2119 [RFC2119]. 126 This document assumes familiarity with DTLS 1.2 [RFC6347]. 128 3. The "connection_id" Extension 130 This document defines the "connection_id" extension, which is used in 131 ClientHello and ServerHello messages. 133 The extension type is specified as follows. 135 enum { 136 connection_id(TBD1), (65535) 137 } ExtensionType; 139 The extension_data field of this extension, when included in the 140 ClientHello, MUST contain the ConnectionId structure. This structure 141 contains the CID value the client wishes the server to use when 142 sending messages to the client. A zero-length CID value indicates 143 that the client is prepared to send with a CID but does not wish the 144 server to use one when sending. 146 struct { 147 opaque cid<0..2^8-1>; 148 } ConnectionId; 150 A server willing to use CIDs will respond with a "connection_id" 151 extension in the ServerHello, containing the CID it wishes the client 152 to use when sending messages towards it. A zero-length value 153 indicates that the server will send with the client's CID but does 154 not wish the client to include a CID (or again, alternately, to use a 155 zero-length CID). 157 Because each party sends the value in the "connection_id" extension 158 it wants to receive as a CID in encrypted records, it is possible for 159 an endpoint to use a globally constant length for such connection 160 identifiers. This can in turn ease parsing and connection lookup, 161 for example by having the length in question be a compile-time 162 constant. Such implementations MUST still be able to send CIDs of 163 different length to other parties. Implementations that want to use 164 variable-length CIDs are responsible for constructing the CID in such 165 a way that its length can be determined on reception. Note that 166 there is no CID length information included in the record itself. 168 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 169 only. There is no dedicated "CID update" message that allows new 170 CIDs to be established mid-session, because DTLS 1.2 in general does 171 not allow TLS 1.3-style post-handshake messages that do not 172 themselves begin other handshakes. When a DTLS session is resumed or 173 renegotiated, the "connection_id" extension is negotiated afresh. 175 If DTLS peers have not negotiated the use of CIDs then the RFC 176 6347-defined record format and content type MUST be used. 178 If DTLS peers have negotiated the use of a CIDs using the ClientHello 179 and the ServerHello messages then the peers need to take the 180 following steps. 182 The DTLS peers determine whether incoming and outgoing messages need 183 to use the new record format, i.e., the record format containing the 184 CID. The new record format with the the tls12_cid content type is 185 only used once encryption is enabled. Plaintext payloads never use 186 the new record type and the CID content type. 188 For sending, if a zero-length CID has been negotiated then the RFC 189 6347-defined record format and content type MUST be used (see 190 Section 4.1 of [RFC6347]) else the new record layer format with the 191 tls12_cid content type defined in Figure 3 MUST be used. 193 When transmitting a datagram with the tls12_cid content type, the new 194 MAC computation defined in Section 5 MUST be used. 196 For receiving, if the tls12_cid content type is set, then the CID is 197 used to look up the connection and the security association. If the 198 tls12_cid content type is not set, then the connection and security 199 association is looked up by the 5-tuple and a check MUST be made to 200 determine whether the expected CID value is indeed zero length. If 201 the check fails, then the datagram MUST be dropped. 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 true 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. The DTLSInnerPlaintext byte sequence is then 244 encrypted. To create the DTLSCiphertext structure shown in Figure 3 245 the CID is added. 247 struct { 248 opaque content[length]; 249 ContentType real_type; 250 uint8 zeros[length_of_padding]; 251 } DTLSInnerPlaintext; 253 Figure 2: New DTLSInnerPlaintext Payload Structure. 255 content Corresponds to the fragment of a given length. 257 real_type The content type describing the payload. 259 zeros An arbitrary-length run of zero-valued bytes may appear in the 260 cleartext after the type field. This provides an opportunity for 261 senders to pad any DTLS record by a chosen amount as long as the 262 total stays within record size limits. See Section 5.4 of 263 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 264 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 266 struct { 267 ContentType outer_type = tls12_cid; 268 ProtocolVersion version; 269 uint16 epoch; 270 uint48 sequence_number; 271 opaque cid[cid_length]; // New field 272 uint16 length; 273 opaque enc_content[DTLSCiphertext.length]; 274 } DTLSCiphertext; 276 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 278 outer_type The outer content type of a DTLSCiphertext record 279 carrying a CID is always set to tls12_cid(TBD2). The real content 280 type of the record is found in DTLSInnerPlaintext.real_type after 281 decryption. 283 cid The CID value, cid_length bytes long, as agreed at the time the 284 extension has been negotiated. Recall that (as discussed 285 previously) each peer chooses the CID value it will receive and 286 use to identify the connection, so an implementation can choose to 287 always recieve CIDs of a fixed length. If, however, an 288 implementation chooses to receive different lengths of CID, the 289 assigned CID values must be self-delineating since there is no 290 other mechanism available to determine what connection (and thus, 291 what CID length) is in use. 293 enc_content The encrypted form of the serialized DTLSInnerPlaintext 294 structure. 296 All other fields are as defined in RFC 6347. 298 5. Record Payload Protection 300 Several types of ciphers have been defined for use with TLS and DTLS 301 and the MAC calculations for those ciphers differ slightly. 303 This specification modifies the MAC calculation as defined in 304 [RFC6347] and [RFC7366], as well as the definition of the additional 305 data used with AEAD ciphers provided in [RFC6347], for records with 306 content type tls12_cid. The modified algorithm MUST NOT be applied 307 to records that do not carry a CID, i.e., records with content type 308 other than tls12_cid. 310 The following fields are defined in this document; all other fields 311 are as defined in the cited documents. 313 cid Value of the negotiated CID (variable length). 315 cid_length 1 byte field indicating the length of the negotiated CID. 317 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 318 DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 319 2^14. 321 seq_num_placeholder 8 bytes of 0xff 323 Note "+" denotes concatenation. 325 5.1. Block Ciphers 327 The following MAC algorithm applies to block ciphers that do not use 328 the with Encrypt-then-MAC processing described in [RFC7366]. 330 MAC(MAC_write_key, 331 seq_num_placeholder + 332 tls12_cid + 333 cid_length + 334 tls12_cid + 335 DTLSCiphertext.version + 336 epoch + 337 sequence_number + 338 cid + 339 length_of_DTLSInnerPlaintext + 340 DTLSInnerPlaintext.content + 341 DTLSInnerPlaintext.real_type + 342 DTLSInnerPlaintext.zeros 343 ); 345 The rationale behind this construction is to separate the MAC input 346 for DTLS without the connection ID from the MAC input with the 347 connection ID. The former always consists of a sequence number 348 followed by some other content type than tls12_cid; the latter always 349 consists of the seq_num_placeholder followed by tls12_cid. Although 350 2^64-1 is potentially a valid sequence number, tls12_cid will never 351 be a valid content type when the connection ID is not in use. In 352 addition, the epoch and sequence_number are now fed into the MAC in 353 the same order as they appear on the wire. 355 5.2. Block Ciphers with Encrypt-then-MAC processing 357 The following MAC algorithm applies to block ciphers that use the 358 with Encrypt-then-MAC processing described in [RFC7366]. 360 MAC(MAC_write_key, 361 seq_num_placeholder + 362 tls12_cid + 363 cid_length + 364 tls12_cid + 365 DTLSCiphertext.version + 366 epoch + 367 sequence_number + 368 cid + 369 DTLSCiphertext.length + 370 IV + 371 ENC(content + padding + padding_length)); 373 5.3. AEAD Ciphers 375 For ciphers utilizing authenticated encryption with additional data 376 the following modification is made to the additional data 377 calculation. 379 additional_data = seq_num_placeholder + 380 tls12_cid + 381 cid_length + 382 tls12_cid + 383 DTLSCiphertext.version + 384 epoch + 385 sequence_number + 386 cid + 387 length_of_DTLSInnerPlaintext; 389 6. Peer Address Update 391 When a record with a CID is received that has a source address 392 different than the one currently associated with the DTLS connection, 393 the receiver MUST NOT replace the address it uses for sending records 394 to its peer with the source address specified in the received 395 datagram unless the following three conditions are met: 397 - The received datagram has been cryptographically verified using 398 the DTLS record layer processing procedures. 400 - The received datagram is "newer" (in terms of both epoch and 401 sequence number) than the newest datagram received. Reordered 402 datagrams that are sent prior to a change in a peer address might 403 otherwise cause a valid address change to be reverted. This also 404 limits the ability of an attacker to use replayed datagrams to 405 force a spurious address change, which could result in denial of 406 service. An attacker might be able to succeed in changing a peer 407 address if they are able to rewrite source addresses and if 408 replayed packets are able to arrive before any original. 410 - There is a strategy for ensuring that the new peer address is able 411 to receive and process DTLS records. No such test is defined in 412 this specification. 414 The conditions above are necessary to protect against attacks that 415 use datagrams with spoofed addresses or replayed datagrams to trigger 416 attacks. Note that there is no requirement for use of the anti- 417 replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2. Both 418 solutions, the "anti-replay window" or "newer" algorithm, will 419 prevent address updates from replay attacks while the latter will 420 only apply to peer address updates and the former applies to any 421 application layer traffic. 423 Note that datagrams that pass the DTLS cryptographic verification 424 procedures but do not trigger a change of peer address are still 425 valid DTLS records and are still to be passed to the application. 427 Application protocols that implement protection against these attacks 428 depend on being aware of changes in peer addresses so that they can 429 engage the necessary mechanisms. When delivered such an event, an 430 application layer-specific address validation mechanism can be 431 triggered, for example one that is based on successful exchange of a 432 minimal amount of ping-pong traffic with the peer. Alternatively, an 433 DTLS-specific mechanism may be used, as described in 434 [I-D.tschofenig-tls-dtls-rrc]. 436 DTLS implementations MUST silently discard records with bad MACs or 437 that are otherwise invalid. 439 7. Examples 441 Figure 4 shows an example exchange where a CID is used uni- 442 directionally from the client to the server. To indicate that a 443 zero-length CID is present in the "connection_id" extension we use 444 the notation 'connection_id=empty'. 446 Client Server 447 ------ ------ 449 ClientHello --------> 450 (connection_id=empty) 452 <-------- HelloVerifyRequest 453 (cookie) 455 ClientHello --------> 456 (connection_id=empty) 457 (cookie) 459 ServerHello 460 (connection_id=100) 461 Certificate 462 ServerKeyExchange 463 CertificateRequest 464 <-------- ServerHelloDone 466 Certificate 467 ClientKeyExchange 468 CertificateVerify 469 [ChangeCipherSpec] 470 Finished --------> 471 473 [ChangeCipherSpec] 474 <-------- Finished 476 Application Data ========> 477 479 <======== Application Data 481 Legend: 483 <...> indicates that a connection id is used in the record layer 484 (...) indicates an extension 485 [...] indicates a payload other than a handshake message 487 Figure 4: Example DTLS 1.2 Exchange with CID 489 Note: In the example exchange the CID is included in the record layer 490 once encryption is enabled. In DTLS 1.2 only one handshake message 491 is encrypted, namely the Finished message. Since the example shows 492 how to use the CID for payloads sent from the client to the server, 493 only the record layer payloads containing the Finished message or 494 application data include a CID. 496 8. Privacy Considerations 498 The CID replaces the previously used 5-tuple and, as such, introduces 499 an identifier that remains persistent during the lifetime of a DTLS 500 connection. Every identifier introduces the risk of linkability, as 501 explained in [RFC6973]. 503 An on-path adversary observing the DTLS protocol exchanges between 504 the DTLS client and the DTLS server is able to link the observed 505 payloads to all subsequent payloads carrying the same ID pair (for 506 bi-directional communication). Without multi-homing or mobility, the 507 use of the CID exposes the same information as the 5-tuple. 509 With multi-homing, a passive attacker is able to correlate the 510 communication interaction over the two paths and the sequence number 511 makes it possible to correlate packets across CID changes. The lack 512 of a CID update mechanism in DTLS 1.2 makes this extension unsuitable 513 for mobility scenarios where correlation must be considered. 514 Deployments that use DTLS in multi-homing environments and are 515 concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2 516 and switch to DTLS 1.3 where a CID update mechanism is provided and 517 sequence number 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 concern when there is a large 539 asymmetry of request/response message sizes. 541 Additionally, an attacker able to observe the data traffic exchanged 542 between two DTLS peers is able to replay datagrams with modified IP 543 address/port numbers. 545 The topic of peer address updates is discussed in Section 6. 547 10. IANA Considerations 549 IANA is requested to allocate an entry to the existing TLS 550 "ExtensionType Values" registry, defined in [RFC5246], for 551 connection_id(TBD1) as described in the table below. IANA is 552 requested to add an extra column to the TLS ExtensionType Values 553 registry to indicate whether an extension is only applicable to DTLS 554 and to include this document as an additional reference for the 555 registry. 557 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 558 -------------------------------------------------------------------- 559 TBD1 connection_id CH, SH Y N [[This doc]] 561 Note: The value "N" in the Recommended column is set because this 562 extension is intended only for specific use cases. This document 563 describes the behavior of this extension for DTLS 1.2 only; it is not 564 applicable to TLS, and its usage for DTLS 1.3 is described in 565 [I-D.ietf-tls-dtls13]. 567 IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType 568 Registry". The tls12_cid ContentType is only applicable to DTLS 1.2. 570 11. References 572 11.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 580 (TLS) Protocol Version 1.2", RFC 5246, 581 DOI 10.17487/RFC5246, August 2008, 582 . 584 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 585 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 586 January 2012, . 588 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 589 Security (TLS) and Datagram Transport Layer Security 590 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 591 . 593 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 594 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 595 . 597 11.2. Informative References 599 [I-D.ietf-tls-dtls13] 600 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 601 Datagram Transport Layer Security (DTLS) Protocol Version 602 1.3", draft-ietf-tls-dtls13-39 (work in progress), 603 November 2020. 605 [I-D.tschofenig-tls-dtls-rrc] 606 Fossati, T. and H. Tschofenig, "Return Routability Check 607 for DTLS 1.2 and DTLS 1.3", draft-tschofenig-tls-dtls- 608 rrc-01 (work in progress), March 2020. 610 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 611 Morris, J., Hansen, M., and R. Smith, "Privacy 612 Considerations for Internet Protocols", RFC 6973, 613 DOI 10.17487/RFC6973, July 2013, 614 . 616 11.3. URIs 618 [1] mailto:tls@ietf.org 620 [2] https://www1.ietf.org/mailman/listinfo/tls 622 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 624 Appendix A. History 626 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 628 draft-ietf-tls-dtls-connection-id-08 630 - RRC draft moved from normative to informative. 632 draft-ietf-tls-dtls-connection-id-07 634 - Wording changes in the security and privacy consideration and the 635 peer address update sections. 637 draft-ietf-tls-dtls-connection-id-06 639 - Updated IANA considerations 641 - Enhanced security consideration section to describe a potential 642 man-in-the-middle attack concerning address validation. 644 draft-ietf-tls-dtls-connection-id-05 646 - Restructed Section 5 "Record Payload Protection" 648 draft-ietf-tls-dtls-connection-id-04 650 - Editorial simplifications to the 'Record Layer Extensions' and the 651 'Record Payload Protection' sections. 653 - Added MAC calculations for block ciphers with and without Encrypt- 654 then-MAC processing. 656 draft-ietf-tls-dtls-connection-id-03 658 - Updated list of contributors 660 - Updated list of contributors and acknowledgements 662 - Updated example 664 - Changed record layer design 666 - Changed record payload protection 668 - Updated introduction and security consideration section 670 - Author- and affiliation changes 671 - Move to internal content types a la DTLS 1.3. 673 draft-ietf-tls-dtls-connection-id-01 675 - Remove 1.3 based on the WG consensus at IETF 101 677 draft-ietf-tls-dtls-connection-id-00 679 - Initial working group version (containing a solution for DTLS 1.2 680 and 1.3) 682 draft-rescorla-tls-dtls-connection-id-00 684 - Initial version 686 Appendix B. Working Group Information 688 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 690 The discussion list for the IETF TLS working group is located at the 691 e-mail address tls@ietf.org [1]. Information on the group and 692 information on how to subscribe to the list is at 693 https://www1.ietf.org/mailman/listinfo/tls [2] 695 Archives of the list can be found at: https://www.ietf.org/mail- 696 archive/web/tls/current/index.html [3] 698 Appendix C. Contributors 700 Many people have contributed to this specification and we would like 701 to thank the following individuals for their contributions: 703 * Yin Xinxing 704 Huawei 705 yinxinxing@huawei.com 707 * Nikos Mavrogiannopoulos 708 RedHat 709 nmav@redhat.com 711 * Tobias Gondrom 712 tobias.gondrom@gondrom.org 714 Additionally, we would like to thank the Connection ID task force 715 team members: 717 - Martin Thomson (Mozilla) 719 - Christian Huitema (Private Octopus Inc.) 721 - Jana Iyengar (Google) 723 - Daniel Kahn Gillmor (ACLU) 725 - Patrick McManus (Mozilla) 727 - Ian Swett (Google) 729 - Mark Nottingham (Fastly) 731 The task force team discussed various design ideas, including 732 cryptographically generated session ids using hash chains and public 733 key encryption, but dismissed them due to their inefficiency. The 734 approach described in this specification is the simplest possible 735 design that works given the limitations of DTLS 1.2. DTLS 1.3 736 provides better privacy features and developers are encouraged to 737 switch to the new version of DTLS. 739 Finally, we want to thank the IETF TLS working group chairs, Chris 740 Wood, Joseph Salowey, and Sean Turner, for their patience, support 741 and feedback. 743 Appendix D. Acknowledgements 745 We would like to thank Achim Kraus for his review comments and 746 implementation feedback. 748 Authors' Addresses 750 Eric Rescorla (editor) 751 RTFM, Inc. 753 EMail: ekr@rtfm.com 755 Hannes Tschofenig (editor) 756 Arm Limited 758 EMail: hannes.tschofenig@arm.com 759 Thomas Fossati 760 Arm Limited 762 EMail: thomas.fossati@arm.com