idnits 2.17.1 draft-ietf-tls-dtls-connection-id-10.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 (7 March 2021) is 1146 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 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-40 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS E. Rescorla, Ed. 3 Internet-Draft RTFM, Inc. 4 Updates: 6347 (if approved) H. Tschofenig, Ed. 5 Intended status: Standards Track T. Fossati 6 Expires: 8 September 2021 Arm Limited 7 A. Kraus 8 Bosch.IO GmbH 9 7 March 2021 11 Connection Identifiers for DTLS 1.2 12 draft-ietf-tls-dtls-connection-id-10 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 8 September 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 74 3. The "connection_id" Extension . . . . . . . . . . . . . . . . 3 75 4. Record Layer Extensions . . . . . . . . . . . . . . . . . . . 5 76 5. Record Payload Protection . . . . . . . . . . . . . . . . . . 7 77 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 78 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 8 79 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Peer Address Update . . . . . . . . . . . . . . . . . . . . . 9 81 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 11.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 14 89 Appendix B. Working Group Information . . . . . . . . . . . . . 16 90 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 16 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 strategy is defined 412 in 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. The lack of a CID 511 update mechanism in DTLS 1.2 makes this extension unsuitable for 512 mobility scenarios where correlation must be considered. Deployments 513 that use DTLS in multi-homing environments and are concerned about 514 this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 515 1.3 where a CID update mechanism is provided and sequence number 516 encryption is available. 518 The specification introduces record padding for the CID-enhanced 519 record layer, which is a privacy feature not available with the 520 original DTLS 1.2 specification. Padding allows to inflate the size 521 of the ciphertext making traffic analysis more difficult. More 522 details about record padding can be found in Section 5.4 and 523 Appendix E.3 of RFC 8446. 525 Finally, endpoints can use the CID to attach arbitrary per-connection 526 metadata to each record they receive on a given connection. This may 527 be used as a mechanism to communicate per-connection information to 528 on-path observers. There is no straightforward way to address this 529 concern with CIDs that contain arbitrary values. Implementations 530 concerned about this aspect SHOULD refuse to use CIDs. 532 9. Security Considerations 534 An on-path adversary can create reflection attacks against third 535 parties because a DTLS peer has no means to distinguish a genuine 536 address update event (for example, due to a NAT rebinding) from one 537 that is malicious. This attack is of particular concern when the 538 request is small and the response large. See Section 6 for more on 539 address updates. 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", Work in Progress, Internet-Draft, draft-ietf-tls- 603 dtls13-40, 20 January 2021, . 606 [I-D.tschofenig-tls-dtls-rrc] 607 Fossati, T. and H. Tschofenig, "Return Routability Check 608 for DTLS 1.2 and DTLS 1.3", Work in Progress, Internet- 609 Draft, draft-tschofenig-tls-dtls-rrc-01, 2 March 2020, 610 . 613 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 614 Morris, J., Hansen, M., and R. Smith, "Privacy 615 Considerations for Internet Protocols", RFC 6973, 616 DOI 10.17487/RFC6973, July 2013, 617 . 619 Appendix A. History 621 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 623 draft-ietf-tls-dtls-connection-id-10 625 * Clarify privacy impact. 627 * Have security considerations point to Section 6. 629 draft-ietf-tls-dtls-connection-id-09 631 * Changed MAC/additional data calculation. 633 * Disallow sending MAC failure fatal alerts to non-validated peers. 635 * Incorporated editorial review comments by Ben Kaduk. 637 * RRC draft moved from normative to informative. 639 draft-ietf-tls-dtls-connection-id-07 641 * Wording changes in the security and privacy consideration and the 642 peer address update sections. 644 draft-ietf-tls-dtls-connection-id-06 646 * Updated IANA considerations 648 * Enhanced security consideration section to describe a potential 649 man-in-the-middle attack concerning address validation. 651 draft-ietf-tls-dtls-connection-id-05 653 * Restructed Section 5 "Record Payload Protection" 655 draft-ietf-tls-dtls-connection-id-04 657 * Editorial simplifications to the 'Record Layer Extensions' and the 658 'Record Payload Protection' sections. 660 * Added MAC calculations for block ciphers with and without Encrypt- 661 then-MAC processing. 663 draft-ietf-tls-dtls-connection-id-03 665 * Updated list of contributors 667 * Updated list of contributors and acknowledgements 669 * Updated example 671 * Changed record layer design 673 * Changed record payload protection 675 * Updated introduction and security consideration section 677 * Author- and affiliation changes 679 draft-ietf-tls-dtls-connection-id-02 681 * Move to internal content types a la DTLS 1.3. 683 * Remove 1.3 based on the WG consensus at IETF 101 685 draft-ietf-tls-dtls-connection-id-00 687 * Initial working group version (containing a solution for DTLS 1.2 688 and 1.3) 690 draft-rescorla-tls-dtls-connection-id-00 692 * Initial version 694 Appendix B. Working Group Information 696 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 698 The discussion list for the IETF TLS working group is located at the 699 e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on 700 the group and information on how to subscribe to the list is at 701 https://www1.ietf.org/mailman/listinfo/tls 702 (https://www1.ietf.org/mailman/listinfo/tls) 704 Archives of the list can be found at: https://www.ietf.org/mail- 705 archive/web/tls/current/index.html (https://www.ietf.org/mail- 706 archive/web/tls/current/index.html) 708 Appendix C. Contributors 710 Many people have contributed to this specification and we would like 711 to thank the following individuals for their contributions: 713 * Yin Xinxing 714 Huawei 715 yinxinxing@huawei.com 717 * Nikos Mavrogiannopoulos 718 RedHat 719 nmav@redhat.com 721 * Tobias Gondrom 722 tobias.gondrom@gondrom.org 724 Additionally, we would like to thank the Connection ID task force 725 team members: 727 * Martin Thomson (Mozilla) 728 * Christian Huitema (Private Octopus Inc.) 730 * Jana Iyengar (Google) 732 * Daniel Kahn Gillmor (ACLU) 734 * Patrick McManus (Mozilla) 736 * Ian Swett (Google) 738 * Mark Nottingham (Fastly) 740 The task force team discussed various design ideas, including 741 cryptographically generated session ids using hash chains and public 742 key encryption, but dismissed them due to their inefficiency. The 743 approach described in this specification is the simplest possible 744 design that works given the limitations of DTLS 1.2. DTLS 1.3 745 provides better privacy features and developers are encouraged to 746 switch to the new version of DTLS. 748 Finally, we want to thank the IETF TLS working group chairs, Chris 749 Wood, Joseph Salowey, and Sean Turner, for their patience, support 750 and feedback. 752 Authors' Addresses 754 Eric Rescorla (editor) 755 RTFM, Inc. 757 Email: ekr@rtfm.com 759 Hannes Tschofenig (editor) 760 Arm Limited 762 Email: hannes.tschofenig@arm.com 764 Thomas Fossati 765 Arm Limited 767 Email: thomas.fossati@arm.com 769 Achim Kraus 770 Bosch.IO GmbH 772 Email: achim.kraus@bosch.io