idnits 2.17.1 draft-ietf-tls-dtls-connection-id-07.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 (October 21, 2019) is 1620 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 438, but not defined -- Looks like a reference, but probably isn't: '1' on line 651 -- Looks like a reference, but probably isn't: '2' on line 653 -- Looks like a reference, but probably isn't: '3' on line 656 == Outdated reference: A later version (-01) exists of draft-tschofenig-tls-dtls-rrc-00 ** 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-33 Summary: 2 errors (**), 0 flaws (~~), 4 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: April 23, 2020 Arm Limited 7 October 21, 2019 9 Connection Identifiers for DTLS 1.2 10 draft-ietf-tls-dtls-connection-id-07 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 April 23, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 86 11.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 14 88 Appendix B. Working Group Information . . . . . . . . . . . . . 15 89 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 15 90 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The Datagram Transport Layer Security (DTLS) protocol was designed 96 for securing connection-less transports, like UDP. DTLS, like TLS, 97 starts with a handshake, which can be computationally demanding 98 (particularly when public key cryptography is used). After a 99 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 longer period of time since the established keys will only 105 need to be updated once the key lifetime expires. 107 In the current version of DTLS, 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. Implementations, which want to use variable-length CIDs, 165 are responsible for constructing the CID in such a way that its 166 length can be determined on reception. Such implementations must 167 still be able to send CIDs of different length to other parties. 168 Note that there is no CID length information included in the record 169 itself. 171 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 172 only. There is no dedicated "CID update" message that allows new 173 CIDs to be established mid-session, because DTLS 1.2 in general does 174 not allow TLS 1.3-style post-handshake messages that do not 175 themselves begin other handshakes. When a DTLS session is resumed or 176 renegotiated, the "connection_id" extension is negotiated afresh. 178 If DTLS peers have not negotiated the use of CIDs then the RFC 179 6347-defined record format and content type MUST be used. 181 If DTLS peers have negotiated the use of a CIDs using the ClientHello 182 and the ServerHello messages then the peers need to take the 183 following steps. 185 The DTLS peers determine whether incoming and outgoing messages need 186 to use the new record format, i.e., the record format containing the 187 CID. The new record format with the the tls12_cid content type is 188 only used once encryption is enabled. Plaintext payloads never use 189 the new record type and the CID content type. 191 For sending, if a zero-length CID has been negotiated then the RFC 192 6347-defined record format and content type MUST be used (see 193 Section 4.1 of [RFC6347]) else the new record layer format with the 194 tls12_cid content type defined in Figure 3 MUST be used. 196 When transmitting a datagram with the tls12_cid content type, the new 197 MAC computation defined in Section 5 MUST be used. 199 For receiving, if the tls12_cid content type is set, then the CID is 200 used to look up the connection and the security association. If the 201 tls12_cid content type is not set, then the connection and security 202 association is looked up by the 5-tuple and a check MUST be made to 203 determine whether the expected CID value is indeed zero length. If 204 the check fails, then the datagram MUST be dropped. 206 When receiving a datagram with the tls12_cid content type, the new 207 MAC computation defined in Section 5 MUST be used. When receiving a 208 datagram with the RFC 6347-defined record format the MAC calculation 209 defined in Section 4.1.2 of [RFC6347] MUST be used. 211 4. Record Layer Extensions 213 This specification defines the DTLS 1.2 record layer format and 214 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 216 To allow a receiver to determine whether a record has a CID or not, 217 connections which have negotiated this extension use a distinguished 218 record type tls12_cid(TBD2). Use of this content type has the 219 following three implications: 221 - The CID field is present and contains one or more bytes. 223 - The MAC calculation follows the process described in Section 5. 225 - The true content type is inside the encryption envelope, as 226 described below. 228 Plaintext records are not impacted by this extension. Hence, the 229 format of the DTLSPlaintext structure is left unchanged, as shown in 230 Figure 1. 232 struct { 233 ContentType type; 234 ProtocolVersion version; 235 uint16 epoch; 236 uint48 sequence_number; 237 uint16 length; 238 opaque fragment[DTLSPlaintext.length]; 239 } DTLSPlaintext; 241 Figure 1: DTLS 1.2 Plaintext Record Payload. 243 When CIDs are being used, the content to be sent is first wrapped 244 along with its content type and optional padding into a 245 DTLSInnerPlaintext structure. This newly introduced structure is 246 shown in Figure 2. The DTLSInnerPlaintext byte sequence is then 247 encrypted. To create the DTLSCiphertext structure shown in Figure 3 248 the CID is added. 250 struct { 251 opaque content[length]; 252 ContentType real_type; 253 uint8 zeros[length_of_padding]; 254 } DTLSInnerPlaintext; 256 Figure 2: New DTLSInnerPlaintext Payload Structure. 258 content Corresponds to the fragment of a given length. 260 real_type The content type describing the payload. 262 zeros An arbitrary-length run of zero-valued bytes may appear in the 263 cleartext after the type field. This provides an opportunity for 264 senders to pad any DTLS record by a chosen amount as long as the 265 total stays within record size limits. See Section 5.4 of 266 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 267 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 269 struct { 270 ContentType special_type = tls12_cid; 271 ProtocolVersion version; 272 uint16 epoch; 273 uint48 sequence_number; 274 opaque cid[cid_length]; // New field 275 uint16 length; 276 opaque enc_content[DTLSCiphertext.length]; 277 } DTLSCiphertext; 279 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 281 special_type The outer content type of a DTLSCiphertext record 282 carrying a CID is always set to tls12_cid(TBD2). The real content 283 type of the record is found in DTLSInnerPlaintext.real_type after 284 decryption. 286 cid The CID value, cid_length bytes long, as agreed at the time the 287 extension has been negotiated. 289 enc_content The encrypted form of the serialized DTLSInnerPlaintext 290 structure. 292 All other fields are as defined in RFC 6347. 294 5. Record Payload Protection 296 Several types of ciphers have been defined for use with TLS and DTLS 297 and the MAC calculation for those ciphers differs slightly. 299 This specification modifies the MAC calculation defined in [RFC6347] 300 and [RFC7366] as well as the definition of the additional data used 301 with AEAD ciphers provided in [RFC6347] for records with content type 302 tls12_cid. The modified algorithm MUST NOT be applied to records 303 that do not carry a CID, i.e., records with content type other than 304 tls12_cid. 306 The following fields are defined in this document; all other fields 307 are as defined in the cited documents. 309 cid Value of the negotiated CID. 311 cid_length 1 byte field indicating the length of the negotiated CID. 313 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 314 DTLSInnerPlaintext. 315 The length MUST NOT exceed 2^14. 317 Note "+" denotes concatenation. 319 5.1. Block Ciphers 321 The following MAC algorithm applies to block ciphers that do not use 322 the with Encrypt-then-MAC processing described in [RFC7366]. 324 MAC(MAC_write_key, seq_num + 325 tls12_cid + 326 DTLSCiphertext.version + 327 cid + 328 cid_length + 329 length_of_DTLSInnerPlaintext + 330 DTLSInnerPlaintext.content + 331 DTLSInnerPlaintext.real_type + 332 DTLSInnerPlaintext.zeros 333 ) 335 5.2. Block Ciphers with Encrypt-then-MAC processing 337 The following MAC algorithm applies to block ciphers that use the 338 with Encrypt-then-MAC processing described in [RFC7366]. 340 MAC(MAC_write_key, seq_num + 341 tls12_cid + 342 DTLSCipherText.version + 343 cid + 344 cid_length + 345 length of (IV + DTLSCiphertext.enc_content) + 346 IV + 347 DTLSCiphertext.enc_content); 349 5.3. AEAD Ciphers 351 For ciphers utilizing authenticated encryption with additional data 352 the following modification is made to the additional data 353 calculation. 355 additional_data = seq_num + 356 tls12_cid + 357 DTLSCipherText.version + 358 cid + 359 cid_length + 360 length_of_DTLSInnerPlaintext; 362 6. Peer Address Update 364 When a record with a CID is received that has a source address 365 different than the one currently associated with the DTLS connection, 366 the receiver MUST NOT replace the address it uses for sending records 367 to its peer with the source address specified in the received 368 datagram unless the following conditions are met: 370 - The received datagram has been cryptographically verified using 371 the DTLS record layer processing procedures. 373 - The received datagram is "newer" (in terms of both epoch and 374 sequence number) than the newest datagram received. Reordered 375 datagrams that are sent prior to a change in a peer address might 376 otherwise cause a valid address change to be reverted. This also 377 limits the ability of an attacker to use replayed datagrams to 378 force a spurious address change, which could result in denial of 379 service. An attacker might be able to succeed in changing a peer 380 address if they are able to rewrite source addresses and if 381 replayed packets are able to arrive before any original. 383 - There is a strategy for ensuring that the new peer address is able 384 to receive and process DTLS records. No such test is defined in 385 this specification. 387 The above is necessary to protect against attacks that use datagrams 388 with spoofed addresses or replayed datagrams to trigger attacks. 389 Note that there is no requirement to use of the anti-replay window 390 mechanism defined in Section 4.1.2.6 of DTLS 1.2. Both solutions, 391 the "anti-replay window" or "newer algorithm" will prevent address 392 updates from replay attacks while the latter will only apply to peer 393 address updates and the former applies to any application layer 394 traffic. 396 Application protocols that implement protection against these attacks 397 depend on being aware of changes in peer addresses so that they can 398 engage the necessary mechanisms. When delivered such an event, an 399 application layer-specific address validation mechanism can be 400 triggered, for example one that is based on successful exchange of 401 minimal amount of ping-pong traffic with the peer. Alternatively, an 402 DTLS-specific mechanism may be used, as described in 403 [I-D.tschofenig-tls-dtls-rrc]. 405 7. Examples 407 Figure 4 shows an example exchange where a CID is used uni- 408 directionally from the client to the server. To indicate that a 409 zero-length CID we use the term 'connection_id=empty'. 411 Client Server 412 ------ ------ 414 ClientHello --------> 415 (connection_id=empty) 417 <-------- HelloVerifyRequest 418 (cookie) 420 ClientHello --------> 421 (connection_id=empty) 422 (cookie) 424 ServerHello 425 (connection_id=100) 426 Certificate 427 ServerKeyExchange 428 CertificateRequest 429 <-------- ServerHelloDone 431 Certificate 432 ClientKeyExchange 433 CertificateVerify 434 [ChangeCipherSpec] 435 Finished --------> 436 438 [ChangeCipherSpec] 439 <-------- Finished 441 Application Data ========> 442 444 <======== Application Data 446 Legend: 448 <...> indicates that a connection id is used in the record layer 449 (...) indicates an extension 450 [...] indicates a payload other than a handshake message 452 Figure 4: Example DTLS 1.2 Exchange with CID 454 Note: In the example exchange the CID is included in the record layer 455 once encryption is enabled. In DTLS 1.2 only one handshake message 456 is encrypted, namely the Finished message. Since the example shows 457 how to use the CID for payloads sent from the client to the server 458 only the record layer payloads containing the Finished messages 459 include a CID. Application data payloads sent from the client to the 460 server contain a CID in this example as well. 462 8. Privacy Considerations 464 The CID replaces the previously used 5-tuple and, as such, introduces 465 an identifier that remains persistent during the lifetime of a DTLS 466 connection. Every identifier introduces the risk of linkability, as 467 explained in [RFC6973]. 469 An on-path adversary observing the DTLS protocol exchanges between 470 the DTLS client and the DTLS server is able to link the observed 471 payloads to all subsequent payloads carrying the same ID pair (for 472 bi-directional communication). Without multi-homing or mobility, the 473 use of the CID exposes the same information as the 5-tuple. 475 With multi-homing, a passive attacker is able to correlate the 476 communication interaction over the two paths and the sequence number 477 makes it possible to correlate packets across CID changes. The lack 478 of a CID update mechanism in DTLS 1.2 makes this extension unsuitable 479 for mobility scenarios where correlation must be considered. 480 Deployments that use DTLS in multi-homing environments and are 481 concerned about this aspects SHOULD refuse to use CIDs in DTLS 1.2 482 and switch to DTLS 1.3 where a CID update mechanism is provided and 483 sequence number encryption is available. 485 The specification introduces record padding for the CID-enhanced 486 record layer, which is a privacy feature not available with the 487 original DTLS 1.2 specification. Padding allows to inflate the size 488 of the ciphertext making traffic analysis more difficult. More 489 details about record padding can be found in Section 5.4 and 490 Appendix E.3 of RFC 8446. 492 Finally, endpoints can use the CID to attach arbitrary metadata to 493 each record they receive. This may be used as a mechanism to 494 communicate per-connection information to on-path observers. There 495 is no straightforward way to address this concern with CIDs that 496 contain arbitrary values. Implementations concerned about this 497 aspects SHOULD refuse to use CIDs. 499 9. Security Considerations 501 An on-path adversary can create reflection attacks against third 502 parties because a DTLS peer has no means to distinguish a genuine 503 address update event (for example, due to a NAT rebinding) from one 504 that is malicious. This attack is of concern when there is a large 505 asymmetry of request/response message sizes. 507 Additionally, an attacker able to observe the data traffic exchanged 508 between two DTLS peers is able to replay datagrams with modified IP 509 address/port numbers. 511 The topic of peer address updates is discussed in Section 6. 513 10. IANA Considerations 515 IANA is requested to allocate an entry to the existing TLS 516 "ExtensionType Values" registry, defined in [RFC5246], for 517 connection_id(TBD1) as described in the table below. IANA is 518 requested to add an extra column to the TLS ExtensionType Values 519 registry to indicate whether an extension is only applicable to DTLS. 521 Value Extension Name TLS 1.3 DTLS Only Recommended Reference 522 -------------------------------------------------------------------- 523 TBD1 connection_id - Y N [[This doc]] 525 Note: The value "N" in the Recommended column is set because this 526 extension is intended only for specific use cases. This document 527 describes an extension for DTLS 1.2 only; it is not to TLS (1.3). 528 The DTLS 1.3 functionality is described in [I-D.ietf-tls-dtls13]. 530 IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType 531 Registry". The tls12_cid ContentType is only applicable to DTLS 1.2. 533 11. References 535 11.1. Normative References 537 [I-D.tschofenig-tls-dtls-rrc] 538 Fossati, T. and H. Tschofenig, "Return Routability Check 539 for DTLS 1.2 and DTLS 1.3", draft-tschofenig-tls-dtls- 540 rrc-00 (work in progress), July 2019. 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, 544 DOI 10.17487/RFC2119, March 1997, 545 . 547 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 548 (TLS) Protocol Version 1.2", RFC 5246, 549 DOI 10.17487/RFC5246, August 2008, 550 . 552 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 553 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 554 January 2012, . 556 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 557 Security (TLS) and Datagram Transport Layer Security 558 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 559 . 561 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 562 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 563 . 565 11.2. Informative References 567 [I-D.ietf-tls-dtls13] 568 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 569 Datagram Transport Layer Security (DTLS) Protocol Version 570 1.3", draft-ietf-tls-dtls13-33 (work in progress), October 571 2019. 573 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 574 Morris, J., Hansen, M., and R. Smith, "Privacy 575 Considerations for Internet Protocols", RFC 6973, 576 DOI 10.17487/RFC6973, July 2013, 577 . 579 11.3. URIs 581 [1] mailto:tls@ietf.org 583 [2] https://www1.ietf.org/mailman/listinfo/tls 585 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 587 Appendix A. History 589 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 591 draft-ietf-tls-dtls-connection-id-07 593 - Wording changes in the security and privacy consideration and the 594 peer address update sections. 596 draft-ietf-tls-dtls-connection-id-06 598 - Updated IANA considerations 600 - Enhanced security consideration section to describe a potential 601 man-in-the-middle attack concerning address validation. 603 draft-ietf-tls-dtls-connection-id-05 605 - Restructed Section 5 "Record Payload Protection" 607 draft-ietf-tls-dtls-connection-id-04 609 - Editorial simplifications to the 'Record Layer Extensions' and the 610 'Record Payload Protection' sections. 612 - Added MAC calculations for block ciphers with and without Encrypt- 613 then-MAC processing. 615 draft-ietf-tls-dtls-connection-id-03 617 - Updated list of contributors 619 - Updated list of contributors and acknowledgements 621 - Updated example 623 - Changed record layer design 625 - Changed record payload protection 627 - Updated introduction and security consideration section 629 - Author- and affiliation changes 631 draft-ietf-tls-dtls-connection-id-02 633 - Move to internal content types a la DTLS 1.3. 635 - Remove 1.3 based on the WG consensus at IETF 101 637 draft-ietf-tls-dtls-connection-id-00 639 - Initial working group version (containing a solution for DTLS 1.2 640 and 1.3) 642 draft-rescorla-tls-dtls-connection-id-00 644 - Initial version 646 Appendix B. Working Group Information 648 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 650 The discussion list for the IETF TLS working group is located at the 651 e-mail address tls@ietf.org [1]. Information on the group and 652 information on how to subscribe to the list is at 653 https://www1.ietf.org/mailman/listinfo/tls [2] 655 Archives of the list can be found at: https://www.ietf.org/mail- 656 archive/web/tls/current/index.html [3] 658 Appendix C. Contributors 660 Many people have contributed to this specification and we would like 661 to thank the following individuals for their contributions: 663 * Yin Xinxing 664 Huawei 665 yinxinxing@huawei.com 667 * Nikos Mavrogiannopoulos 668 RedHat 669 nmav@redhat.com 671 * Tobias Gondrom 672 tobias.gondrom@gondrom.org 674 Additionally, we would like to thank the Connection ID task force 675 team members: 677 - Martin Thomson (Mozilla) 679 - Christian Huitema (Private Octopus Inc.) 680 - Jana Iyengar (Google) 682 - Daniel Kahn Gillmor (ACLU) 684 - Patrick McManus (Mozilla) 686 - Ian Swett (Google) 688 - Mark Nottingham (Fastly) 690 The task force team discussed various design ideas, including 691 cryptographically generated session 692 ids using hash chains and public key encryption, but dismissed them 693 due to their inefficiency. The approach described in this 694 specification is the simplest possible design that works given the 695 limitations of DTLS 1.2. DTLS 1.3 provides better privacy features 696 and developers are encouraged to switch to the new version of DTLS. 698 Finally, we want to thank the IETF TLS working group chairs, Chris 699 Wood, Joseph Salowey, and Sean Turner, for their patience, support 700 and feedback. 702 Appendix D. Acknowledgements 704 We would like to thank Achim Kraus for his review comments and 705 implementation feedback. 707 Authors' Addresses 709 Eric Rescorla (editor) 710 RTFM, Inc. 712 EMail: ekr@rtfm.com 714 Hannes Tschofenig (editor) 715 Arm Limited 717 EMail: hannes.tschofenig@arm.com 719 Thomas Fossati 720 Arm Limited 722 EMail: thomas.fossati@arm.com