idnits 2.17.1 draft-ietf-tls-dtls-connection-id-08.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 (November 02, 2020) is 1270 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 452, but not defined -- Looks like a reference, but probably isn't: '1' on line 670 -- Looks like a reference, but probably isn't: '2' on line 672 -- Looks like a reference, but probably isn't: '3' on line 675 ** 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-38 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: May 6, 2021 Arm Limited 7 November 02, 2020 9 Connection Identifiers for DTLS 1.2 10 draft-ietf-tls-dtls-connection-id-08 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 May 6, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . 8 79 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 8 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. Alternatively, this can be 145 interpreted as the client wishes the server to use a zero-length CID; 146 the result is the same. 148 struct { 149 opaque cid<0..2^8-1>; 150 } ConnectionId; 152 A server willing to use CIDs will respond with a "connection_id" 153 extension in the ServerHello, containing the CID it wishes the client 154 to use when sending messages towards it. A zero-length value 155 indicates that the server will send with the client's CID but does 156 not wish the client to include a CID (or again, alternately, to use a 157 zero-length CID). 159 Because each party sends the value in the "connection_id" extension 160 it wants to receive as a CID in encrypted records, it is possible for 161 an endpoint to use a globally constant length for such connection 162 identifiers. This can in turn ease parsing and connection lookup, 163 for example by having the length in question be a compile-time 164 constant. Such implementations MUST still be able to send CIDs of 165 different length to other parties. Implementations that want to use 166 variable-length CIDs are responsible for constructing the CID in such 167 a way that its length can be determined on reception. Note that 168 there is no CID length information included in the record itself. 170 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 171 only. There is no dedicated "CID update" message that allows new 172 CIDs to be established mid-session, because DTLS 1.2 in general does 173 not allow TLS 1.3-style post-handshake messages that do not 174 themselves begin other handshakes. When a DTLS session is resumed or 175 renegotiated, the "connection_id" extension is negotiated afresh. 177 If DTLS peers have not negotiated the use of CIDs then the RFC 178 6347-defined record format and content type MUST be used. 180 If DTLS peers have negotiated the use of a CIDs using the ClientHello 181 and the ServerHello messages then the peers need to take the 182 following steps. 184 The DTLS peers determine whether incoming and outgoing messages need 185 to use the new record format, i.e., the record format containing the 186 CID. The new record format with the the tls12_cid content type is 187 only used once encryption is enabled. Plaintext payloads never use 188 the new record type and the CID content type. 190 For sending, if a zero-length CID has been negotiated then the RFC 191 6347-defined record format and content type MUST be used (see 192 Section 4.1 of [RFC6347]) else the new record layer format with the 193 tls12_cid content type defined in Figure 3 MUST be used. 195 When transmitting a datagram with the tls12_cid content type, the new 196 MAC computation defined in Section 5 MUST be used. 198 For receiving, if the tls12_cid content type is set, then the CID is 199 used to look up the connection and the security association. If the 200 tls12_cid content type is not set, then the connection and security 201 association is looked up by the 5-tuple and a check MUST be made to 202 determine whether the expected CID value is indeed zero length. If 203 the check fails, then the datagram MUST be dropped. 205 When receiving a datagram with the tls12_cid content type, the new 206 MAC computation defined in Section 5 MUST be used. When receiving a 207 datagram with the RFC 6347-defined record format the MAC calculation 208 defined in Section 4.1.2 of [RFC6347] MUST be used. 210 4. Record Layer Extensions 212 This specification defines the DTLS 1.2 record layer format and 213 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 215 To allow a receiver to determine whether a record has a CID or not, 216 connections which have negotiated this extension use a distinguished 217 record type tls12_cid(TBD2). Use of this content type has the 218 following three implications: 220 - The CID field is present and contains one or more bytes. 222 - The MAC calculation follows the process described in Section 5. 224 - The true content type is inside the encryption envelope, as 225 described below. 227 Plaintext records are not impacted by this extension. Hence, the 228 format of the DTLSPlaintext structure is left unchanged, as shown in 229 Figure 1. 231 struct { 232 ContentType type; 233 ProtocolVersion version; 234 uint16 epoch; 235 uint48 sequence_number; 236 uint16 length; 237 opaque fragment[DTLSPlaintext.length]; 238 } DTLSPlaintext; 240 Figure 1: DTLS 1.2 Plaintext Record Payload. 242 When CIDs are being used, the content to be sent is first wrapped 243 along with its content type and optional padding into a 244 DTLSInnerPlaintext structure. This newly introduced structure is 245 shown in Figure 2. The DTLSInnerPlaintext byte sequence is then 246 encrypted. To create the DTLSCiphertext structure shown in Figure 3 247 the CID is added. 249 struct { 250 opaque content[length]; 251 ContentType real_type; 252 uint8 zeros[length_of_padding]; 253 } DTLSInnerPlaintext; 255 Figure 2: New DTLSInnerPlaintext Payload Structure. 257 content Corresponds to the fragment of a given length. 259 real_type The content type describing the payload. 261 zeros An arbitrary-length run of zero-valued bytes may appear in the 262 cleartext after the type field. This provides an opportunity for 263 senders to pad any DTLS record by a chosen amount as long as the 264 total stays within record size limits. See Section 5.4 of 265 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 266 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 268 struct { 269 ContentType outer_type = tls12_cid; 270 ProtocolVersion version; 271 uint16 epoch; 272 uint48 sequence_number; 273 opaque cid[cid_length]; // New field 274 uint16 length; 275 opaque enc_content[DTLSCiphertext.length]; 276 } DTLSCiphertext; 278 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 280 outer_type The outer content type of a DTLSCiphertext record 281 carrying a CID is always set to tls12_cid(TBD2). The real content 282 type of the record is found in DTLSInnerPlaintext.real_type after 283 decryption. 285 cid The CID value, cid_length bytes long, as agreed at the time the 286 extension has been negotiated. Recall that (as discussed 287 previously) each peer chooses the CID value it will receive and 288 use to identify the connection, so an implementation can choose to 289 always recieve CIDs of a fixed length. If, however, an 290 implementation chooses to receive different lengths of CID, the 291 assigned CID values must be self-delineating since there is no 292 other mechanism available to determine what connection (and thus, 293 what CID length) is in use. 295 enc_content The encrypted form of the serialized DTLSInnerPlaintext 296 structure. 298 All other fields are as defined in RFC 6347. 300 5. Record Payload Protection 302 Several types of ciphers have been defined for use with TLS and DTLS 303 and the MAC calculations for those ciphers differ slightly. 305 This specification modifies the MAC calculation as defined in 306 [RFC6347] and [RFC7366], as well as the definition of the additional 307 data used with AEAD ciphers provided in [RFC6347], for records with 308 content type tls12_cid. The modified algorithm MUST NOT be applied 309 to records that do not carry a CID, i.e., records with content type 310 other than tls12_cid. 312 The following fields are defined in this document; all other fields 313 are as defined in the cited documents. 315 cid Value of the negotiated CID (variable length). 317 cid_length 1 byte field indicating the length of the negotiated CID. 319 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 320 DTLSInnerPlaintext (two-byte integer). 321 The length MUST NOT exceed 2^14. 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, seq_num + 331 tls12_cid + 332 DTLSCiphertext.version + 333 cid + 334 cid_length + 335 length_of_DTLSInnerPlaintext + 336 DTLSInnerPlaintext.content + 337 DTLSInnerPlaintext.real_type + 338 DTLSInnerPlaintext.zeros 339 ) 341 5.2. Block Ciphers with Encrypt-then-MAC processing 343 The following MAC algorithm applies to block ciphers that use the 344 with Encrypt-then-MAC processing described in [RFC7366]. 346 MAC(MAC_write_key, seq_num + 347 tls12_cid + 348 DTLSCipherText.version + 349 cid + 350 cid_length + 351 length of (IV + DTLSCiphertext.enc_content) + 352 IV + 353 DTLSCiphertext.enc_content); 355 5.3. AEAD Ciphers 357 For ciphers utilizing authenticated encryption with additional data 358 the following modification is made to the additional data 359 calculation. 361 additional_data = seq_num + 362 tls12_cid + 363 DTLSCipherText.version + 364 cid + 365 cid_length + 366 length_of_DTLSInnerPlaintext; 368 6. Peer Address Update 370 When a record with a CID is received that has a source address 371 different than the one currently associated with the DTLS connection, 372 the receiver MUST NOT replace the address it uses for sending records 373 to its peer with the source address specified in the received 374 datagram unless the following three conditions are met: 376 - The received datagram has been cryptographically verified using 377 the DTLS record layer processing procedures. 379 - The received datagram is "newer" (in terms of both epoch and 380 sequence number) than the newest datagram received. Reordered 381 datagrams that are sent prior to a change in a peer address might 382 otherwise cause a valid address change to be reverted. This also 383 limits the ability of an attacker to use replayed datagrams to 384 force a spurious address change, which could result in denial of 385 service. An attacker might be able to succeed in changing a peer 386 address if they are able to rewrite source addresses and if 387 replayed packets are able to arrive before any original. 389 - There is a strategy for ensuring that the new peer address is able 390 to receive and process DTLS records. No such test is defined in 391 this specification. 393 The conditions above are necessary to protect against attacks that 394 use datagrams with spoofed addresses or replayed datagrams to trigger 395 attacks. Note that there is no requirement for use of the anti- 396 replay window mechanism defined in Section 4.1.2.6 of DTLS 1.2. Both 397 solutions, the "anti-replay window" or "newer" algorithm, will 398 prevent address updates from replay attacks while the latter will 399 only apply to peer address updates and the former applies to any 400 application layer traffic. 402 Note that datagrams that pass the DTLS cryptographic verification 403 procedures but do not trigger a change of peer address are still 404 valid DTLS records and are still to be passed to the application. 406 Application protocols that implement protection against these attacks 407 depend on being aware of changes in peer addresses so that they can 408 engage the necessary mechanisms. When delivered such an event, an 409 application layer-specific address validation mechanism can be 410 triggered, for example one that is based on successful exchange of a 411 minimal amount of ping-pong traffic with the peer. Alternatively, an 412 DTLS-specific mechanism may be used, as described in 413 [I-D.tschofenig-tls-dtls-rrc]. 415 DTLS implementations MUST silently discard records with bad MACs or 416 that are otherwise invalid. 418 7. Examples 420 Figure 4 shows an example exchange where a CID is used uni- 421 directionally from the client to the server. To indicate that a 422 zero-length CID is present in the "connection_id" extension we use 423 the notation 'connection_id=empty'. 425 Client Server 426 ------ ------ 428 ClientHello --------> 429 (connection_id=empty) 431 <-------- HelloVerifyRequest 432 (cookie) 434 ClientHello --------> 435 (connection_id=empty) 436 (cookie) 438 ServerHello 439 (connection_id=100) 440 Certificate 441 ServerKeyExchange 442 CertificateRequest 443 <-------- ServerHelloDone 445 Certificate 446 ClientKeyExchange 447 CertificateVerify 448 [ChangeCipherSpec] 449 Finished --------> 450 452 [ChangeCipherSpec] 453 <-------- Finished 455 Application Data ========> 456 458 <======== Application Data 460 Legend: 462 <...> indicates that a connection id is used in the record layer 463 (...) indicates an extension 464 [...] indicates a payload other than a handshake message 466 Figure 4: Example DTLS 1.2 Exchange with CID 468 Note: In the example exchange the CID is included in the record layer 469 once encryption is enabled. In DTLS 1.2 only one handshake message 470 is encrypted, namely the Finished message. Since the example shows 471 how to use the CID for payloads sent from the client to the server, 472 only the record layer payloads containing the Finished message or 473 application data include a CID. 475 8. Privacy Considerations 477 The CID replaces the previously used 5-tuple and, as such, introduces 478 an identifier that remains persistent during the lifetime of a DTLS 479 connection. Every identifier introduces the risk of linkability, as 480 explained in [RFC6973]. 482 An on-path adversary observing the DTLS protocol exchanges between 483 the DTLS client and the DTLS server is able to link the observed 484 payloads to all subsequent payloads carrying the same ID pair (for 485 bi-directional communication). Without multi-homing or mobility, the 486 use of the CID exposes the same information as the 5-tuple. 488 With multi-homing, a passive attacker is able to correlate the 489 communication interaction over the two paths and the sequence number 490 makes it possible to correlate packets across CID changes. The lack 491 of a CID update mechanism in DTLS 1.2 makes this extension unsuitable 492 for mobility scenarios where correlation must be considered. 493 Deployments that use DTLS in multi-homing environments and are 494 concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2 495 and switch to DTLS 1.3 where a CID update mechanism is provided and 496 sequence number encryption is available. 498 The specification introduces record padding for the CID-enhanced 499 record layer, which is a privacy feature not available with the 500 original DTLS 1.2 specification. Padding allows to inflate the size 501 of the ciphertext making traffic analysis more difficult. More 502 details about record padding can be found in Section 5.4 and 503 Appendix E.3 of RFC 8446. 505 Finally, endpoints can use the CID to attach arbitrary per-connection 506 metadata to each record they receive on a given connection. This may 507 be used as a mechanism to communicate per-connection information to 508 on-path observers. There is no straightforward way to address this 509 concern with CIDs that contain arbitrary values. Implementations 510 concerned about this aspect SHOULD refuse to use CIDs. 512 9. Security Considerations 514 An on-path adversary can create reflection attacks against third 515 parties because a DTLS peer has no means to distinguish a genuine 516 address update event (for example, due to a NAT rebinding) from one 517 that is malicious. This attack is of concern when there is a large 518 asymmetry of request/response message sizes. 520 Additionally, an attacker able to observe the data traffic exchanged 521 between two DTLS peers is able to replay datagrams with modified IP 522 address/port numbers. 524 The topic of peer address updates is discussed in Section 6. 526 10. IANA Considerations 528 IANA is requested to allocate an entry to the existing TLS 529 "ExtensionType Values" registry, defined in [RFC5246], for 530 connection_id(TBD1) as described in the table below. IANA is 531 requested to add an extra column to the TLS ExtensionType Values 532 registry to indicate whether an extension is only applicable to DTLS 533 and to include this document as an additional reference for the 534 registry. 536 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 537 -------------------------------------------------------------------- 538 TBD1 connection_id CH, SH Y N [[This doc]] 540 Note: The value "N" in the Recommended column is set because this 541 extension is intended only for specific use cases. This document 542 describes the behavior of this extension for DTLS 1.2 only; it is not 543 applicable to TLS, and its usage for DTLS 1.3 is described in 544 [I-D.ietf-tls-dtls13]. 546 IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType 547 Registry". The tls12_cid ContentType is only applicable to DTLS 1.2. 549 11. References 551 11.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 559 (TLS) Protocol Version 1.2", RFC 5246, 560 DOI 10.17487/RFC5246, August 2008, 561 . 563 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 564 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 565 January 2012, . 567 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 568 Security (TLS) and Datagram Transport Layer Security 569 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 570 . 572 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 573 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 574 . 576 11.2. Informative References 578 [I-D.ietf-tls-dtls13] 579 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 580 Datagram Transport Layer Security (DTLS) Protocol Version 581 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 582 2020. 584 [I-D.tschofenig-tls-dtls-rrc] 585 Fossati, T. and H. Tschofenig, "Return Routability Check 586 for DTLS 1.2 and DTLS 1.3", draft-tschofenig-tls-dtls- 587 rrc-01 (work in progress), March 2020. 589 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 590 Morris, J., Hansen, M., and R. Smith, "Privacy 591 Considerations for Internet Protocols", RFC 6973, 592 DOI 10.17487/RFC6973, July 2013, 593 . 595 11.3. URIs 597 [1] mailto:tls@ietf.org 599 [2] https://www1.ietf.org/mailman/listinfo/tls 601 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 603 Appendix A. History 605 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 607 draft-ietf-tls-dtls-connection-id-08 609 - RRC draft moved from normative to informative. 611 draft-ietf-tls-dtls-connection-id-07 613 - Wording changes in the security and privacy consideration and the 614 peer address update sections. 616 draft-ietf-tls-dtls-connection-id-06 618 - Updated IANA considerations 620 - Enhanced security consideration section to describe a potential 621 man-in-the-middle attack concerning address validation. 623 draft-ietf-tls-dtls-connection-id-05 625 - Restructed Section 5 "Record Payload Protection" 627 draft-ietf-tls-dtls-connection-id-04 629 - Editorial simplifications to the 'Record Layer Extensions' and the 630 'Record Payload Protection' sections. 632 - Added MAC calculations for block ciphers with and without Encrypt- 633 then-MAC processing. 635 draft-ietf-tls-dtls-connection-id-03 637 - Updated list of contributors 639 - Updated list of contributors and acknowledgements 641 - Updated example 643 - Changed record layer design 645 - Changed record payload protection 647 - Updated introduction and security consideration section 649 - Author- and affiliation changes 650 - Move to internal content types a la DTLS 1.3. 652 draft-ietf-tls-dtls-connection-id-01 654 - Remove 1.3 based on the WG consensus at IETF 101 656 draft-ietf-tls-dtls-connection-id-00 658 - Initial working group version (containing a solution for DTLS 1.2 659 and 1.3) 661 draft-rescorla-tls-dtls-connection-id-00 663 - Initial version 665 Appendix B. Working Group Information 667 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 669 The discussion list for the IETF TLS working group is located at the 670 e-mail address tls@ietf.org [1]. Information on the group and 671 information on how to subscribe to the list is at 672 https://www1.ietf.org/mailman/listinfo/tls [2] 674 Archives of the list can be found at: https://www.ietf.org/mail- 675 archive/web/tls/current/index.html [3] 677 Appendix C. Contributors 679 Many people have contributed to this specification and we would like 680 to thank the following individuals for their contributions: 682 * Yin Xinxing 683 Huawei 684 yinxinxing@huawei.com 686 * Nikos Mavrogiannopoulos 687 RedHat 688 nmav@redhat.com 690 * Tobias Gondrom 691 tobias.gondrom@gondrom.org 693 Additionally, we would like to thank the Connection ID task force 694 team members: 696 - Martin Thomson (Mozilla) 698 - Christian Huitema (Private Octopus Inc.) 700 - Jana Iyengar (Google) 702 - Daniel Kahn Gillmor (ACLU) 704 - Patrick McManus (Mozilla) 706 - Ian Swett (Google) 708 - Mark Nottingham (Fastly) 710 The task force team discussed various design ideas, including 711 cryptographically generated session 712 ids using hash chains and public key encryption, but dismissed them 713 due to their inefficiency. The approach described in this 714 specification is the simplest possible design that works given the 715 limitations of DTLS 1.2. DTLS 1.3 provides better privacy features 716 and developers are encouraged to switch to the new version of DTLS. 718 Finally, we want to thank the IETF TLS working group chairs, Chris 719 Wood, Joseph Salowey, and Sean Turner, for their patience, support 720 and feedback. 722 Appendix D. Acknowledgements 724 We would like to thank Achim Kraus for his review comments and 725 implementation feedback. 727 Authors' Addresses 729 Eric Rescorla (editor) 730 RTFM, Inc. 732 EMail: ekr@rtfm.com 734 Hannes Tschofenig (editor) 735 Arm Limited 737 EMail: hannes.tschofenig@arm.com 738 Thomas Fossati 739 Arm Limited 741 EMail: thomas.fossati@arm.com