idnits 2.17.1 draft-ietf-tls-dtls-connection-id-04.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 document seems to lack a Security Considerations section. -- 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 (March 11, 2019) is 1871 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 367, but not defined -- Looks like a reference, but probably isn't: '1' on line 527 -- Looks like a reference, but probably isn't: '2' on line 529 -- Looks like a reference, but probably isn't: '3' on line 532 ** 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-30 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: September 12, 2019 Arm Limited 7 March 11, 2019 9 Connection Identifiers for DTLS 1.2 10 draft-ietf-tls-dtls-connection-id-04 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 September 12, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7. Security and Privacy Considerations . . . . . . . . . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 13 83 Appendix B. Working Group Information . . . . . . . . . . . . . 13 84 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 14 85 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The Datagram Transport Layer Security (DTLS) protocol was designed 91 for securing connection-less transports, like UDP. DTLS, like TLS, 92 starts with a handshake, which can be computationally demanding 93 (particularly when public key cryptography is used). After a 94 successful handshake, symmetric key cryptography is used to apply 95 data origin authentication, integrity and confidentiality protection. 96 This two-step approach allows endpoints to amortize the cost of the 97 initial handshake across subsequent application data protection. 98 Ideally, the second phase where application data is protected lasts 99 over a longer period of time since the established keys will only 100 need to be updated once the key lifetime expires. 102 In the current version of DTLS, the IP address and port of the peer 103 are used to identify the DTLS association. Unfortunately, in some 104 cases, such as NAT rebinding, these values are insufficient. This is 105 a particular issue in the Internet of Things when devices enter 106 extended sleep periods to increase their battery lifetime. The NAT 107 rebinding leads to connection failure, with the resulting cost of a 108 new handshake. 110 This document defines an extension to DTLS 1.2 to add a CID to the 111 DTLS record layer. The presence of the CID is negotiated via a DTLS 112 extension. 114 2. Conventions and Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in RFC 119 2119 [RFC2119]. 121 This document assumes familiarity with DTLS 1.2 [RFC6347]. 123 3. The "connection_id" Extension 125 This document defines the "connection_id" extension, which is used in 126 ClientHello and ServerHello messages. 128 The extension type is specified as follows. 130 enum { 131 connection_id(TBD), (65535) 132 } ExtensionType; 134 The extension_data field of this extension, when included in the 135 ClientHello, MUST contain the ConnectionId structure. This structure 136 contains the CID value the client wishes the server to use when 137 sending messages to the client. A zero-length CID value indicates 138 that the client is prepared to send with a CID but does not wish the 139 server to use one when sending. Alternatively, this can be 140 interpreted as the client wishes the server to use a zero-length CID; 141 the result is the same. 143 struct { 144 opaque cid<0..2^8-1>; 145 } ConnectionId; 147 A server willing to use CIDs will respond with a "connection_id" 148 extension in the ServerHello, containing the CID it wishes the client 149 to use when sending messages towards it. A zero-length value 150 indicates that the server will send with the client's CID but does 151 not wish the client to include a CID (or again, alternately, to use a 152 zero-length CID). 154 Because each party sends the value in the "connection_id" extension 155 it wants to receive as a CID in encrypted records, it is possible for 156 an endpoint to use a globally constant length for such connection 157 identifiers. This can in turn ease parsing and connection lookup, 158 for example by having the length in question be a compile-time 159 constant. Implementations, which want to use variable-length CIDs, 160 are responsible for constructing the CID in such a way that its 161 length can be determined on reception. Such implementations must 162 still be able to send CIDs of different length to other parties. 163 Note that there is no CID length information included in the record 164 itself. 166 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 167 only. There is no dedicated "CID update" message that allows new 168 CIDs to be established mid-session, because DTLS 1.2 in general does 169 not allow TLS 1.3-style post-handshake messages that do not 170 themselves begin other handshakes. When a DTLS session is resumed or 171 renegotiated, the "connection_id" extension is negotiated afresh. 173 If DTLS peers have not negotiated the use of CIDs then the RFC 174 6347-defined record format and content type MUST be used. 176 If DTLS peers have negotiated the use of a CIDs using the ClientHello 177 and the ServerHello messages then the peers need to take the 178 following steps. 180 The DTLS peers determine whether incoming and outgoing messages need 181 to use the new record format, i.e., the record format containing the 182 CID. The new record format with the the tls12_cid content type is 183 only used once encryption is enabled. Plaintext payloads never use 184 the new record type and the CID content type. 186 For sending, if a zero-length CID has been negotiated then the RFC 187 6347-defined record format and content type MUST be used (see 188 Section 4.1 of [RFC6347]) else the new record layer format with the 189 tls12_cid content type defined in Figure 1 MUST be used. 191 When transmitting a datagram with the tls12_cid content type, the new 192 MAC computation defined in Section 5 MUST be used. 194 For receiving, if the tls12_cid content type is set, then the CID is 195 used to look up the connection and the security association. If the 196 tls12_cid content type is not set, then the connection and security 197 association is looked up by the 5-tuple and a check MUST be made to 198 determine whether the expected CID value is indeed zero length. If 199 the check fails, then the datagram MUST be dropped. 201 When receiving a datagram with the tls12_cid content type, the new 202 MAC computation defined in Section 5 MUST be used. When receiving a 203 datagram with the RFC 6347-defined record format the MAC calculation 204 defined in Section 4.1.2 of [RFC6347] MUST be used. 206 4. Record Layer Extensions 208 This specification defines the DTLS 1.2 record layer format and 209 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 211 To allow a receiver to determine whether a record has a CID or not, 212 connections which have negotiated this extension use a distinguished 213 record type tls12_cid(25). Use of this content type has the 214 following three implications: 216 - The CID field is present and contains one or more bytes. 218 - The MAC calculation follows the process described in Section 5. 220 - The true content type is inside the encryption envelope, as 221 described below. 223 When CIDs are being used, the content to be sent is first wrapped 224 along with its content type and optional padding into a 225 DTLSInnerPlaintext: 227 struct { 228 ContentType type; 229 ProtocolVersion version; 230 uint16 epoch; 231 uint48 sequence_number; 232 uint16 length; 233 opaque fragment[DTLSPlaintext.length]; 234 } DTLSPlaintext; 236 struct { 237 opaque content[DTLSPlaintext.length]; 238 ContentType real_type; 239 uint8 zeros[length_of_padding]; 240 } DTLSInnerPlaintext; 242 content A copy of DTLSPlaintext.fragment 244 real_type A copy of DTLSPlaintext.type 246 zeros An arbitrary-length run of zero-valued bytes may appear in the 247 cleartext after the type field. This provides an opportunity for 248 senders to pad any DTLS record by a chosen amount as long as the 249 total stays within record size limits. See Section 5.4 of 250 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 251 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 253 The DTLSInnerPlaintext value is then encrypted and the CID added to 254 produce the final DTLSCiphertext. 256 struct { 257 ContentType special_type = tls12_cid; /* 25 */ 258 ProtocolVersion version; 259 uint16 epoch; 260 uint48 sequence_number; 261 opaque cid[cid_length]; // New field 262 uint16 length; 263 opaque enc_content[DTLSCiphertext.length]; 264 } DTLSCiphertext; 266 Figure 1: DTLSCiphertext with CID 268 special_type The outer content type of a DTLSCiphertext record 269 carrying a CID is always set to the value 25 (tls12_cid). The 270 actual content type of the record is found in 271 DTLSInnerPlaintext.real_type after decryption. 273 cid The CID value, cid_length bytes long, as agreed at the time the 274 extension has been negotiated. 276 enc_content The encrypted form of the serialized DTLSInnerPlaintext 277 structure. 279 All other fields are as defined in RFC 6347. 281 5. Record Payload Protection 283 This specification modifies the MAC calculation defined in [RFC6347] 284 and [RFC7366] as well as the definition of the additional data used 285 with AEAD ciphers provided in [RFC6347] for records with content type 286 tls12_cid. The modified algorithm MUST NOT be applied to records 287 that do not carry a CID, i.e., records with content type other than 288 tls12_cid. 290 - Block Ciphers: 292 MAC(MAC_write_key, seq_num + 293 tls12_cid + // New input 294 DTLSPlaintext.version + 295 cid + // New input 296 cid_length + // New input 297 length_of_DTLSInnerPlaintext + // New input 298 DTLSInnerPlaintext.content + // New input 299 DTLSInnerPlaintext.real_type + // New input 300 DTLSInnerPlaintext.zeros // New input 301 ) 303 - Block Ciphers with Encrypt-then-MAC processing: 305 MAC(MAC_write_key, seq_num + 306 DTLSCipherText.type + 307 DTLSCipherText.version + 308 DTLSPlaintext.version + 309 cid + // New input 310 cid_length + // New input 311 length of (IV + DTLSCiphertext.enc_content) + 312 IV + 313 DTLSCiphertext.enc_content); 315 - AEAD Ciphers: 317 additional_data = seq_num + DTLSPlaintext.type + 318 DTLSPlaintext.version + 319 cid + // New input 320 cid_length + // New input 321 length_of_DTLSInnerPlaintext; 323 Where: 325 cid Value of the negotiated CID. 327 cid_length 1 byte field indicating the length of the negotiated CID. 329 All other fields are as defined in the cited documents. 331 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 332 DTLSInnerPlaintext. The length MUST NOT exceed 2^14. 334 6. Examples 336 Figure 2 shows an example exchange where a CID is used uni- 337 directionally from the client to the server. To indicate that a 338 zero-length CID we use the term 'connection_id=empty'. 340 Client Server 341 ------ ------ 343 ClientHello --------> 344 (connection_id=empty) 346 <-------- HelloVerifyRequest 347 (cookie) 349 ClientHello --------> 350 (connection_id=empty) 351 (cookie) 353 ServerHello 354 (connection_id=100) 355 Certificate 356 ServerKeyExchange 357 CertificateRequest 358 <-------- ServerHelloDone 360 Certificate 361 ClientKeyExchange 362 CertificateVerify 363 [ChangeCipherSpec] 364 Finished --------> 365 367 [ChangeCipherSpec] 368 <-------- Finished 370 Application Data ========> 371 373 <======== Application Data 375 Legend: 377 <...> indicates that a connection id is used in the record layer 378 (...) indicates an extension 379 [...] indicates a payload other than a handshake message 381 Figure 2: Example DTLS 1.2 Exchange with CID 383 Note: In the example exchange the CID is included in the record layer 384 once encryption is enabled. In DTLS 1.2 only one handshake message 385 is encrypted, namely the Finished message. Since the example shows 386 how to use the CID for payloads sent from the client to the server 387 only the record layer payload containing the Finished messagen 388 contains a CID. Application data payloads sent from the client to 389 the server contain a CID in this example as well. 391 7. Security and Privacy Considerations 393 The CID replaces the previously used 5-tuple and, as such, introduces 394 an identifier that remains persistent during the lifetime of a DTLS 395 connection. Every identifier introduces the risk of linkability, as 396 explained in [RFC6973]. 398 In addition, endpoints can use the CID to attach arbitrary metadata 399 to each record they receive. This may be used as a mechanism to 400 communicate per-connection information to on-path observers. There 401 is no straightforward way to address this with CIDs that contain 402 arbitrary values; implementations concerned about this SHOULD refuse 403 to use connection ids. 405 An on-path adversary, who is able to observe the DTLS protocol 406 exchanges between the DTLS client and the DTLS server, is able to 407 link the observed payloads to all subsequent payloads carrying the 408 same connection id pair (for bi-directional communication). Without 409 multi-homing or mobility, the use of the CID is not different to the 410 use of the 5-tuple. 412 With multi-homing, an adversary is able to correlate the 413 communication interaction over the two paths, which adds further 414 privacy concerns. 416 Importantly, the sequence number makes it possible for a passive 417 attacker to correlate packets across CID changes. Thus, even if a 418 client/server pair do a rehandshake to change CID, that does not 419 provide much privacy benefit. 421 The CID-enhanced record layer introduces record padding; a privacy 422 feature not available with the original DTLS 1.2 RFC. Padding allows 423 to inflate the size of the ciphertext making traffic analysis more 424 difficult. More details about the padding can be found in 425 Section 5.4 and Appendix E.3 of RFC 8446. 427 8. IANA Considerations 429 IANA is requested to allocate an entry to the existing TLS 430 "ExtensionType Values" registry, defined in [RFC5246], for 431 connection_id(TBD) defined in this document. 433 IANA is requested to allocate tls12_cid(25) in the "TLS ContentType 434 Registry". 436 9. References 438 9.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 446 (TLS) Protocol Version 1.2", RFC 5246, 447 DOI 10.17487/RFC5246, August 2008, 448 . 450 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 451 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 452 January 2012, . 454 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 455 Security (TLS) and Datagram Transport Layer Security 456 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 457 . 459 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 460 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 461 . 463 9.2. Informative References 465 [I-D.ietf-tls-dtls13] 466 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 467 Datagram Transport Layer Security (DTLS) Protocol Version 468 1.3", draft-ietf-tls-dtls13-30 (work in progress), 469 November 2018. 471 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 472 Morris, J., Hansen, M., and R. Smith, "Privacy 473 Considerations for Internet Protocols", RFC 6973, 474 DOI 10.17487/RFC6973, July 2013, 475 . 477 9.3. URIs 479 [1] mailto:tls@ietf.org 481 [2] https://www1.ietf.org/mailman/listinfo/tls 483 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 485 Appendix A. History 487 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 489 draft-ietf-tls-dtls-connection-id-03 491 - Updated list of contributors 493 - Updated list of contributors and acknowledgements 495 - Updated example 497 - Changed record layer design 499 - Changed record payload protection 501 - Updated introduction and security consideration section 503 - Author- and affiliation changes 505 draft-ietf-tls-dtls-connection-id-02 507 - Move to internal content types a la DTLS 1.3. 509 draft-ietf-tls-dtls-connection-id-01 511 - Remove 1.3 based on the WG consensus at IETF 101 513 draft-ietf-tls-dtls-connection-id-00 515 - Initial working group version (containing a solution for DTLS 1.2 516 and 1.3) 518 draft-rescorla-tls-dtls-connection-id-00 520 - Initial version 522 Appendix B. Working Group Information 524 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 526 The discussion list for the IETF TLS working group is located at the 527 e-mail address tls@ietf.org [1]. Information on the group and 528 information on how to subscribe to the list is at 529 https://www1.ietf.org/mailman/listinfo/tls [2] 531 Archives of the list can be found at: https://www.ietf.org/mail- 532 archive/web/tls/current/index.html [3] 534 Appendix C. Contributors 536 Many people have contributed to this specification and we would like 537 to thank the following individuals for their contributions: 539 * Yin Xinxing 540 Huawei 541 yinxinxing@huawei.com 543 * Nikos Mavrogiannopoulos 544 RedHat 545 nmav@redhat.com 547 * Tobias Gondrom 548 tobias.gondrom@gondrom.org 550 Additionally, we would like to thank the Connection ID task force 551 team members: 553 - Martin Thomson (Mozilla) 555 - Christian Huitema (Private Octopus Inc.) 557 - Jana Iyengar (Google) 559 - Daniel Kahn Gillmor (ACLU) 561 - Patrick McManus (Mozilla) 563 - Ian Swett (Google) 565 - Mark Nottingham (Fastly) 567 The task force team discussed various design ideas, including 568 cryptographically generated session 569 ids using hash chains and public key encryption, but dismissed them 570 due to their inefficiency. The approach described in this 571 specification is the simplest possible design that works given the 572 limitations of DTLS 1.2. DTLS 1.3 provides better privacy features 573 and developers are encouraged to switch to the new version of DTLS, 574 if these privacy properties are important in a given deployment. 576 Finally, we want to thank the IETF TLS working group chairs, Chris 577 Wood, Joseph Salowey, and Sean Turner, for their patience, support 578 and feedback. 580 Appendix D. Acknowledgements 582 We would like to thank Achim Kraus for his review feedback. 584 Authors' Addresses 586 Eric Rescorla (editor) 587 RTFM, Inc. 589 EMail: ekr@rtfm.com 591 Hannes Tschofenig (editor) 592 Arm Limited 594 EMail: hannes.tschofenig@arm.com 596 Thomas Fossati 597 Arm Limited 599 EMail: thomas.fossati@arm.com