idnits 2.17.1 draft-ietf-tls-dtls-connection-id-05.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 (May 06, 2019) is 1810 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 393, but not defined -- Looks like a reference, but probably isn't: '1' on line 563 -- Looks like a reference, but probably isn't: '2' on line 565 -- Looks like a reference, but probably isn't: '3' on line 568 ** 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-31 Summary: 3 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: November 7, 2019 Arm Limited 7 May 06, 2019 9 Connection Identifiers for DTLS 1.2 10 draft-ietf-tls-dtls-connection-id-05 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 November 7, 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 5.1. Block Ciphers . . . . . . . . . . . . . . . . . . . . . . 7 77 5.2. Block Ciphers with Encrypt-then-MAC processing . . . . . 7 78 5.3. AEAD Ciphers . . . . . . . . . . . . . . . . . . . . . . 8 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Security and Privacy Considerations . . . . . . . . . . . . . 10 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 9.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 13 86 Appendix B. Working Group Information . . . . . . . . . . . . . 14 87 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 14 88 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 The Datagram Transport Layer Security (DTLS) protocol was designed 94 for securing connection-less transports, like UDP. DTLS, like TLS, 95 starts with a handshake, which can be computationally demanding 96 (particularly when public key cryptography is used). After a 97 successful handshake, symmetric key cryptography is used to apply 98 data origin authentication, integrity and confidentiality protection. 99 This two-step approach allows endpoints to amortize the cost of the 100 initial handshake across subsequent application data protection. 101 Ideally, the second phase where application data is protected lasts 102 over a longer period of time since the established keys will only 103 need to be updated once the key lifetime expires. 105 In the current version of DTLS, the IP address and port of the peer 106 are used to identify the DTLS association. Unfortunately, in some 107 cases, such as NAT rebinding, these values are insufficient. This is 108 a particular issue in the Internet of Things when devices enter 109 extended sleep periods to increase their battery lifetime. The NAT 110 rebinding leads to connection failure, with the resulting cost of a 111 new handshake. 113 This document defines an extension to DTLS 1.2 to add a CID to the 114 DTLS record layer. The presence of the CID is negotiated via a DTLS 115 extension. 117 2. Conventions and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in RFC 122 2119 [RFC2119]. 124 This document assumes familiarity with DTLS 1.2 [RFC6347]. 126 3. The "connection_id" Extension 128 This document defines the "connection_id" extension, which is used in 129 ClientHello and ServerHello messages. 131 The extension type is specified as follows. 133 enum { 134 connection_id(TBD1), (65535) 135 } ExtensionType; 137 The extension_data field of this extension, when included in the 138 ClientHello, MUST contain the ConnectionId structure. This structure 139 contains the CID value the client wishes the server to use when 140 sending messages to the client. A zero-length CID value indicates 141 that the client is prepared to send with a CID but does not wish the 142 server to use one when sending. Alternatively, this can be 143 interpreted as the client wishes the server to use a zero-length CID; 144 the result is the same. 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. Implementations, which want to use variable-length CIDs, 163 are responsible for constructing the CID in such a way that its 164 length can be determined on reception. Such implementations must 165 still be able to send CIDs of different length to other parties. 166 Note that there is no CID length information included in the record 167 itself. 169 In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session 170 only. There is no dedicated "CID update" message that allows new 171 CIDs to be established mid-session, because DTLS 1.2 in general does 172 not allow TLS 1.3-style post-handshake messages that do not 173 themselves begin other handshakes. When a DTLS session is resumed or 174 renegotiated, the "connection_id" extension is negotiated afresh. 176 If DTLS peers have not negotiated the use of CIDs then the RFC 177 6347-defined record format and content type MUST be used. 179 If DTLS peers have negotiated the use of a CIDs using the ClientHello 180 and the ServerHello messages then the peers need to take the 181 following steps. 183 The DTLS peers determine whether incoming and outgoing messages need 184 to use the new record format, i.e., the record format containing the 185 CID. The new record format with the the tls12_cid content type is 186 only used once encryption is enabled. Plaintext payloads never use 187 the new record type and the CID content type. 189 For sending, if a zero-length CID has been negotiated then the RFC 190 6347-defined record format and content type MUST be used (see 191 Section 4.1 of [RFC6347]) else the new record layer format with the 192 tls12_cid content type defined in Figure 3 MUST be used. 194 When transmitting a datagram with the tls12_cid content type, the new 195 MAC computation defined in Section 5 MUST be used. 197 For receiving, if the tls12_cid content type is set, then the CID is 198 used to look up the connection and the security association. If the 199 tls12_cid content type is not set, then the connection and security 200 association is looked up by the 5-tuple and a check MUST be made to 201 determine whether the expected CID value is indeed zero length. If 202 the check fails, then the datagram MUST be dropped. 204 When receiving a datagram with the tls12_cid content type, the new 205 MAC computation defined in Section 5 MUST be used. When receiving a 206 datagram with the RFC 6347-defined record format the MAC calculation 207 defined in Section 4.1.2 of [RFC6347] MUST be used. 209 4. Record Layer Extensions 211 This specification defines the DTLS 1.2 record layer format and 212 [I-D.ietf-tls-dtls13] specifies how to carry the CID in DTLS 1.3. 214 To allow a receiver to determine whether a record has a CID or not, 215 connections which have negotiated this extension use a distinguished 216 record type tls12_cid(TBD2). Use of this content type has the 217 following three implications: 219 - The CID field is present and contains one or more bytes. 221 - The MAC calculation follows the process described in Section 5. 223 - The true content type is inside the encryption envelope, as 224 described below. 226 Plaintext records are not impacted by this extension. Hence, the 227 format of the DTLSPlaintext structure is left unchanged, as shown in 228 Figure 1. 230 struct { 231 ContentType type; 232 ProtocolVersion version; 233 uint16 epoch; 234 uint48 sequence_number; 235 uint16 length; 236 opaque fragment[DTLSPlaintext.length]; 237 } DTLSPlaintext; 239 Figure 1: DTLS 1.2 Plaintext Record Payload. 241 When CIDs are being used, the content to be sent is first wrapped 242 along with its content type and optional padding into a 243 DTLSInnerPlaintext structure. This newly introduced structure is 244 shown in Figure 2. The DTLSInnerPlaintext byte sequence is then 245 encrypted. To create the DTLSCiphertext structure shown in Figure 3 246 the CID is added. 248 struct { 249 opaque content[length]; 250 ContentType real_type; 251 uint8 zeros[length_of_padding]; 252 } DTLSInnerPlaintext; 254 Figure 2: New DTLSInnerPlaintext Payload Structure. 256 content Corresponds to the fragment of a given length. 258 real_type The content type describing the payload. 260 zeros An arbitrary-length run of zero-valued bytes may appear in the 261 cleartext after the type field. This provides an opportunity for 262 senders to pad any DTLS record by a chosen amount as long as the 263 total stays within record size limits. See Section 5.4 of 264 [RFC8446] for more details. (Note that the term TLSInnerPlaintext 265 in RFC 8446 refers to DTLSInnerPlaintext in this specification.) 267 struct { 268 ContentType special_type = tls12_cid; 269 ProtocolVersion version; 270 uint16 epoch; 271 uint48 sequence_number; 272 opaque cid[cid_length]; // New field 273 uint16 length; 274 opaque enc_content[DTLSCiphertext.length]; 275 } DTLSCiphertext; 277 Figure 3: DTLS 1.2 CID-enhanced Ciphertext Record. 279 special_type The outer content type of a DTLSCiphertext record 280 carrying a CID is always set to tls12_cid(TBD2). The real content 281 type of the record is found in DTLSInnerPlaintext.real_type after 282 decryption. 284 cid The CID value, cid_length bytes long, as agreed at the time the 285 extension has been negotiated. 287 enc_content The encrypted form of the serialized DTLSInnerPlaintext 288 structure. 290 All other fields are as defined in RFC 6347. 292 5. Record Payload Protection 294 Several types of ciphers have been defined for use with TLS and DTLS 295 and the MAC calculation for those ciphers differs slightly. 297 This specification modifies the MAC calculation defined in [RFC6347] 298 and [RFC7366] as well as the definition of the additional data used 299 with AEAD ciphers provided in [RFC6347] for records with content type 300 tls12_cid. The modified algorithm MUST NOT be applied to records 301 that do not carry a CID, i.e., records with content type other than 302 tls12_cid. 304 The following fields are defined in this document; all other fields 305 are as defined in the cited documents. 307 cid Value of the negotiated CID. 309 cid_length 1 byte field indicating the length of the negotiated CID. 311 length_of_DTLSInnerPlaintext The length (in bytes) of the serialised 312 DTLSInnerPlaintext. 313 The length MUST NOT exceed 2^14. 315 Note "+" denotes concatenation. 317 5.1. Block Ciphers 319 The following MAC algorithm applies to block ciphers that do not use 320 the with Encrypt-then-MAC processing described in [RFC7366]. 322 MAC(MAC_write_key, seq_num + 323 tls12_cid + 324 DTLSCiphertext.version + 325 cid + 326 cid_length + 327 length_of_DTLSInnerPlaintext + 328 DTLSInnerPlaintext.content + 329 DTLSInnerPlaintext.real_type + 330 DTLSInnerPlaintext.zeros 331 ) 333 5.2. Block Ciphers with Encrypt-then-MAC processing 335 The following MAC algorithm applies to block ciphers that use the 336 with Encrypt-then-MAC processing described in [RFC7366]. 338 MAC(MAC_write_key, seq_num + 339 tls12_cid + 340 DTLSCipherText.version + 341 cid + 342 cid_length + 343 length of (IV + DTLSCiphertext.enc_content) + 344 IV + 345 DTLSCiphertext.enc_content); 347 5.3. AEAD Ciphers 349 For ciphers utilizing authenticated encryption with additional data 350 the following modification is made to the additional data 351 calculation. 353 additional_data = seq_num + 354 tls12_cid + 355 DTLSCipherText.version + 356 cid + 357 cid_length + 358 length_of_DTLSInnerPlaintext; 360 6. Examples 362 Figure 4 shows an example exchange where a CID is used uni- 363 directionally from the client to the server. To indicate that a 364 zero-length CID we use the term 'connection_id=empty'. 366 Client Server 367 ------ ------ 369 ClientHello --------> 370 (connection_id=empty) 372 <-------- HelloVerifyRequest 373 (cookie) 375 ClientHello --------> 376 (connection_id=empty) 377 (cookie) 379 ServerHello 380 (connection_id=100) 381 Certificate 382 ServerKeyExchange 383 CertificateRequest 384 <-------- ServerHelloDone 386 Certificate 387 ClientKeyExchange 388 CertificateVerify 389 [ChangeCipherSpec] 390 Finished --------> 391 393 [ChangeCipherSpec] 394 <-------- Finished 396 Application Data ========> 397 399 <======== Application Data 401 Legend: 403 <...> indicates that a connection id is used in the record layer 404 (...) indicates an extension 405 [...] indicates a payload other than a handshake message 407 Figure 4: Example DTLS 1.2 Exchange with CID 409 Note: In the example exchange the CID is included in the record layer 410 once encryption is enabled. In DTLS 1.2 only one handshake message 411 is encrypted, namely the Finished message. Since the example shows 412 how to use the CID for payloads sent from the client to the server 413 only the record layer payload containing the Finished messagen 414 contains a CID. Application data payloads sent from the client to 415 the server contain a CID in this example as well. 417 7. Security and Privacy Considerations 419 The CID replaces the previously used 5-tuple and, as such, introduces 420 an identifier that remains persistent during the lifetime of a DTLS 421 connection. Every identifier introduces the risk of linkability, as 422 explained in [RFC6973]. 424 In addition, endpoints can use the CID to attach arbitrary metadata 425 to each record they receive. This may be used as a mechanism to 426 communicate per-connection information to on-path observers. There 427 is no straightforward way to address this with CIDs that contain 428 arbitrary values; implementations concerned about this SHOULD refuse 429 to use connection ids. 431 An on-path adversary, who is able to observe the DTLS protocol 432 exchanges between the DTLS client and the DTLS server, is able to 433 link the observed payloads to all subsequent payloads carrying the 434 same connection id pair (for bi-directional communication). Without 435 multi-homing or mobility, the use of the CID is not different to the 436 use of the 5-tuple. 438 With multi-homing, an adversary is able to correlate the 439 communication interaction over the two paths, which adds further 440 privacy concerns. The lack of a CID update mechanism makes this 441 extension unsuitable for mobility scenarios where correlation must be 442 considered. 444 Importantly, the sequence number makes it possible for a passive 445 attacker to correlate packets across CID changes. Thus, even if a 446 client/server pair do a rehandshake to change CID, that does not 447 provide much privacy benefit. 449 The CID-enhanced record layer introduces record padding; a privacy 450 feature not available with the original DTLS 1.2 RFC. Padding allows 451 to inflate the size of the ciphertext making traffic analysis more 452 difficult. More details about the padding can be found in 453 Section 5.4 and Appendix E.3 of RFC 8446. 455 8. IANA Considerations 457 IANA is requested to allocate an entry to the existing TLS 458 "ExtensionType Values" registry, defined in [RFC5246], for 459 connection_id(TBD1) defined in this document. 461 IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType 462 Registry". 464 9. References 466 9.1. Normative References 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 474 (TLS) Protocol Version 1.2", RFC 5246, 475 DOI 10.17487/RFC5246, August 2008, 476 . 478 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 479 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 480 January 2012, . 482 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 483 Security (TLS) and Datagram Transport Layer Security 484 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 485 . 487 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 488 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 489 . 491 9.2. Informative References 493 [I-D.ietf-tls-dtls13] 494 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 495 Datagram Transport Layer Security (DTLS) Protocol Version 496 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 497 2019. 499 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 500 Morris, J., Hansen, M., and R. Smith, "Privacy 501 Considerations for Internet Protocols", RFC 6973, 502 DOI 10.17487/RFC6973, July 2013, 503 . 505 9.3. URIs 507 [1] mailto:tls@ietf.org 509 [2] https://www1.ietf.org/mailman/listinfo/tls 511 [3] https://www.ietf.org/mail-archive/web/tls/current/index.html 513 Appendix A. History 515 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 517 draft-ietf-tls-dtls-connection-id-04 519 - Editorial simplifications to the 'Record Layer Extensions' and the 520 'Record Payload Protection' sections. 522 - Added MAC calculations for block ciphers with and without Encrypt- 523 then-MAC processing. 525 draft-ietf-tls-dtls-connection-id-03 527 - Updated list of contributors 529 - Updated list of contributors and acknowledgements 531 - Updated example 533 - Changed record layer design 535 - Changed record payload protection 537 - Updated introduction and security consideration section 539 - Author- and affiliation changes 541 draft-ietf-tls-dtls-connection-id-02 543 - Move to internal content types a la DTLS 1.3. 545 draft-ietf-tls-dtls-connection-id-01 547 - Remove 1.3 based on the WG consensus at IETF 101 549 draft-ietf-tls-dtls-connection-id-00 551 - Initial working group version (containing a solution for DTLS 1.2 552 and 1.3) 554 draft-rescorla-tls-dtls-connection-id-00 556 - Initial version 558 Appendix B. Working Group Information 560 RFC EDITOR: PLEASE REMOVE THE THIS SECTION 562 The discussion list for the IETF TLS working group is located at the 563 e-mail address tls@ietf.org [1]. Information on the group and 564 information on how to subscribe to the list is at 565 https://www1.ietf.org/mailman/listinfo/tls [2] 567 Archives of the list can be found at: https://www.ietf.org/mail- 568 archive/web/tls/current/index.html [3] 570 Appendix C. Contributors 572 Many people have contributed to this specification and we would like 573 to thank the following individuals for their contributions: 575 * Yin Xinxing 576 Huawei 577 yinxinxing@huawei.com 579 * Nikos Mavrogiannopoulos 580 RedHat 581 nmav@redhat.com 583 * Tobias Gondrom 584 tobias.gondrom@gondrom.org 586 Additionally, we would like to thank the Connection ID task force 587 team members: 589 - Martin Thomson (Mozilla) 591 - Christian Huitema (Private Octopus Inc.) 593 - Jana Iyengar (Google) 595 - Daniel Kahn Gillmor (ACLU) 597 - Patrick McManus (Mozilla) 599 - Ian Swett (Google) 601 - Mark Nottingham (Fastly) 603 The task force team discussed various design ideas, including 604 cryptographically generated session 605 ids using hash chains and public key encryption, but dismissed them 606 due to their inefficiency. The approach described in this 607 specification is the simplest possible design that works given the 608 limitations of DTLS 1.2. DTLS 1.3 provides better privacy features 609 and developers are encouraged to switch to the new version of DTLS. 611 Finally, we want to thank the IETF TLS working group chairs, Chris 612 Wood, Joseph Salowey, and Sean Turner, for their patience, support 613 and feedback. 615 Appendix D. Acknowledgements 617 We would like to thank Achim Kraus for his review comments and 618 implementation feedback. 620 Authors' Addresses 622 Eric Rescorla (editor) 623 RTFM, Inc. 625 EMail: ekr@rtfm.com 627 Hannes Tschofenig (editor) 628 Arm Limited 630 EMail: hannes.tschofenig@arm.com 632 Thomas Fossati 633 Arm Limited 635 EMail: thomas.fossati@arm.com