idnits 2.17.00 (12 Aug 2021) /tmp/idnits26028/draft-ietf-dice-profile-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 8, 2014) is 2720 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 741, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM-SMS' == Outdated reference: draft-ietf-tls-cached-info has been published as RFC 7924 == Outdated reference: draft-ietf-tls-session-hash has been published as RFC 7627 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7251 -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP-WDP' -- No information found for draft-bmoeller-tls-downgrade-scsv - is the name correct? -- No information found for draft-bmoeller-tls-falsestart - is the name correct? == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-02 -- No information found for draft-ietf-tls-prohibiting-rc4 - is the name correct? == Outdated reference: draft-ietf-uta-tls-bcp has been published as RFC 7525 == Outdated reference: draft-irtf-cfrg-chacha20-poly1305 has been published as RFC 7539 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dice H. Tschofenig, Ed. 3 Internet-Draft ARM Ltd. 4 Intended status: Standards Track T. Fossati 5 Expires: June 11, 2015 Alcatel-Lucent 6 December 8, 2014 8 A Datagram Transport Layer Security (DTLS) 1.2 Profile for the Internet 9 of Things 10 draft-ietf-dice-profile-06.txt 12 Abstract 14 This document defines a DTLS 1.2 profile that is suitable for 15 Internet of Things applications and is reasonably implementable on 16 many constrained devices. 18 A common design pattern in IoT deployments is the use of a 19 constrained device (typically providing sensor data) that interacts 20 with the web infrastructure. This document focuses on this 21 particular pattern. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 11, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. DTLS Protocol Overview . . . . . . . . . . . . . . . . . . . 4 60 4. The Communication Model . . . . . . . . . . . . . . . . . . . 5 61 5. The Ciphersuite Concept . . . . . . . . . . . . . . . . . . . 7 62 6. Credential Types . . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. Pre-Shared Secret . . . . . . . . . . . . . . . . . . . . 9 64 6.2. Raw Public Key . . . . . . . . . . . . . . . . . . . . . 11 65 6.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 13 66 7. Signature Algorithm Extension . . . . . . . . . . . . . . . . 15 67 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 16 68 9. Session Resumption . . . . . . . . . . . . . . . . . . . . . 17 69 10. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 11. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 18 71 12. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 13. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 14. Random Number Generation . . . . . . . . . . . . . . . . . . 21 74 15. Truncated MAC Extension . . . . . . . . . . . . . . . . . . . 22 75 16. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 22 76 17. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 22 77 18. TLS Session Hash . . . . . . . . . . . . . . . . . . . . . . 23 78 19. Re-Negotiation Attacks . . . . . . . . . . . . . . . . . . . 23 79 20. Downgrading Attacks . . . . . . . . . . . . . . . . . . . . . 23 80 21. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 24 81 22. Key Length Recommendations . . . . . . . . . . . . . . . . . 25 82 23. TLS False Start . . . . . . . . . . . . . . . . . . . . . . . 25 83 24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 84 25. Security Considerations . . . . . . . . . . . . . . . . . . . 27 85 26. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 86 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 87 28. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 88 28.1. Normative References . . . . . . . . . . . . . . . . . . 28 89 28.2. Informative References . . . . . . . . . . . . . . . . . 29 90 Appendix A. Conveying DTLS over SMS . . . . . . . . . . . . . . 32 91 A.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 32 92 A.2. Message Segmentation and Re-Assembly . . . . . . . . . . 33 93 A.3. Multiplexing Security Associations . . . . . . . . . . . 34 94 A.4. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 97 1. Introduction 99 This document defines a DTLS 1.2 [RFC6347] profile that offers 100 communication security for Internet of Things (IoT) applications and 101 is reasonably implementable on many constrained devices. The DTLS 102 1.2 protocol is based on Transport Layer Security (TLS) 1.2 [RFC5246] 103 and provides equivalent security guarantees. This document aims to 104 meet the following goals: 106 o Serves as a one-stop shop for implementers to know which pieces of 107 the specification jungle contain relevant details. 109 o Does not alter the TLS/DTLS specifications. 111 o Does not introduce any new extensions. 113 o Aligns with the DTLS security modes of the Constrained Application 114 Protocol (CoAP) [RFC7252]. 116 DTLS is used to secure a number of applications run over an 117 unreliable datagram transport. CoAP [RFC7252] is one such protocol 118 and has been designed specifically for use in IoT environments. CoAP 119 can be secured a number of different ways, also called security 120 modes. These security modes are as follows, see Section 6.1, 121 Section 6.2, Section 6.3 for additional details: 123 No Security Protection at the Transport Layer: No DTLS is used but 124 instead application layer security functionality is assumed. 126 Shared Secret-based DTLS Authentication: DTLS supports the use of 127 shared secrets [RFC4279]. This mode is useful if the number of 128 communication relationships between the IoT device and servers is 129 small and for very constrained devices. Shared secret-based 130 authentication mechanisms offer good performance and require a 131 minimum of data to be exchanged. 133 DTLS Authentication using Asymmetric Cryptography: TLS supports 134 client and server authentication using asymmetric cryptography. 135 Two approaches for validating these public keys are available. 136 First, [RFC7250] allows raw public keys to be used in TLS without 137 the overhead of certificates. This approach requires out-of-band 138 validation of the public key. Second, the use of X.509 139 certificates [RFC5280] with TLS is common on the Web today (at 140 least for server-side authentication) and certain IoT environments 141 may also re-use those capabilities. Certificates bind an 142 identifier to the public key signed by a certification authority 143 (CA). A trust anchor store has to be provisioned on the device to 144 indicate what CAs are trusted. Furthermore, the certificate may 145 contain a wealth of other information used to make authorization 146 decisions. 148 As described in [I-D.ietf-lwig-tls-minimal], an application designer 149 developing an IoT device needs to consider the security threats and 150 the security services that can be used to mitigate the threats. 151 Enabling devices to upload data and retrieve configuration 152 information, inevitably requires that Internet-connected devices be 153 able to authenticate themselves to servers and vice versa as well as 154 to ensure that the data and information exchanged is integrity and 155 confidentiality protected. While these security services can be 156 provided at different layers in the protocol stack the use of 157 communication security, as offered by DTLS, has been very popular on 158 the Internet and it is likely to be useful for IoT scenarios as well. 159 In case the communication security features offered by DTLS meet the 160 security requirements of your application the remainder of the 161 document might offer useful guidance. 163 Not every IoT deployment will use CoAP but the discussion regarding 164 choice of credentials and cryptographic algorithms will be very 165 similar. As such, the content in this document is applicable beyond 166 the use of the CoAP protocol. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 Note that "Client" and "Server" in this document refer to TLS roles, 175 where the Client initiates the TLS handshake. This does not restrict 176 the interaction pattern of the protocols carried inside TLS as the 177 record layer allows bi-directional communication. In the case of 178 CoAP the "Client" can act as a CoAP Server or Client. 180 RFC 7228 [RFC7228] introduces the notion of constrained-node 181 networks, which are small devices with severe constraints on power, 182 memory, and processing resources. The terms constrained devices, and 183 Internet of Things (IoT) devices are used interchangeably. 185 3. DTLS Protocol Overview 187 The TLS protocol [RFC5246] provides authenticated, confidentiality- 188 and integrity-protected communication between two endpoints. The 189 protocol is composed of two layers: the Record Protocol and the 190 Handshake Protocol. At the lowest level, layered on top of a 191 reliable transport protocol (e.g., TCP), is the Record Protocol. It 192 provides connection security by using symmetric cryptography for 193 confidentiality, data origin authentication, and integrity 194 protection. The Record Protocol is used for encapsulation of various 195 higher-level protocols. One such encapsulated protocol, the TLS 196 Handshake Protocol, allows the server and client to authenticate each 197 other and to negotiate an encryption algorithm and cryptographic keys 198 before the application protocol transmits or receives data. 200 The design of DTLS [RFC6347] is intentionally very similar to TLS. 201 Since DTLS operates on top of an unreliable datagram transport a few 202 enhancements to the TLS structure are, however necessary. RFC 6347 203 explains these differences in great detail. As a short summary, for 204 those not familiar with DTLS the differences are: 206 o An explicit sequence number and an epoch field is included in the 207 TLS Record Layer. Section 4.1 of RFC 6347 explains the processing 208 rules for these two new fields. The value used to compute the MAC 209 is the 64-bit value formed by concatenating the epoch and the 210 sequence number. 212 o Stream ciphers must not be used with DTLS. The only stream cipher 213 defined for TLS 1.2 is RC4 and due to cryptographic weaknesses it 214 is not recommended anymore even for use with TLS 215 [I-D.ietf-tls-prohibiting-rc4]. 217 o The TLS Handshake Protocol has been enhanced to include a 218 stateless cookie exchange for Denial of Service (DoS) resistance. 219 Furthermore, the header has been extended to deal with message 220 loss, reordering, and fragmentation. Retransmission timers have 221 been included to deal with message loss. For DoS protection a new 222 handshake message, the HelloVerifyRequest, was added to DTLS. 223 This handshake message is sent by the server and includes a 224 stateless cookie, which is returned in a ClientHello message back 225 to the server. Although the exchange is optional for the server 226 to execute, a client implementation has to be prepared to respond 227 to it. 229 4. The Communication Model 231 This document describes a profile of DTLS 1.2 and, to be useful, it 232 has to make assumptions about the envisioned communication 233 architecture. 235 The communication architecture shown in Figure 1 assumes a unicast 236 communication interaction with an IoT device utilizing a DTLS client 237 and that client interacts with one or multiple DTLS servers. 239 Before a client can initiate the DTLS handshake it needs to know the 240 IP address of that server and what credentials to use. Application 241 layer protocols, such as CoAP, conveyed on top of DTLS may need 242 additional information, such information about URLs of the endpoints 243 the CoAP needs to register and publish information to. This 244 configuration information (including credentials) may be conveyed to 245 clients as part of a firmware/software package or via a configuration 246 protocol. The following credential types are supported by this 247 profile: 249 o For PSK-based authentication (see Section 6.1), this includes the 250 paired "PSK identity" and shared secret to be used with each 251 server. 253 o For raw public key-based authentication (see Section 6.2), this 254 includes either the server's public key or the hash of the 255 server's public key. 257 o For certificate-based authentication (see Section 6.3), this 258 includes a pre-populated trust anchor store that allows the DTLS 259 stack to perform path validation for the certificate obtained 260 during the handshake with the server. 262 This document focuses on the description of the DTLS client-side 263 functionality but, quite naturally, the equivalent server-side 264 support has to be available. 266 +////////////////////////////////////+ 267 | Configuration | 268 |////////////////////////////////////| 269 | Server A --> PSK Identity, PSK | 270 | Server B --> Public Key (Server B),| 271 | Public Key (Client) | 272 | Server C --> Public Key (Client), | 273 | Trust Anchor Store | 274 +------------------------------------+ 275 oo 276 oooooo 277 o 278 +------+ 279 |Client|--- 280 +------+ \ 281 \ ,-------. 282 ,' `. +------+ 283 / IP-based \ |Server| 284 ( Network ) | A | 285 \ / +------+ 286 `. ,' 287 '---+---' +------+ 288 | |Server| 289 | | B | 290 | +------+ 291 | 292 | +------+ 293 +----------------->|Server| 294 | C | 295 +------+ 297 Figure 1: Constrained DTLS Client Profile. 299 5. The Ciphersuite Concept 301 TLS (and consequently DTLS) has the concept of ciphersuites and an 302 IANA registry [IANA-TLS] was created to register the suites. A 303 ciphersuite (and the specification that defines it) contains the 304 following information: 306 o Authentication and Key Exchange Algorithm (e.g., PSK) 308 o Cipher and Key Length (e.g., Advanced Encryption Standard (AES) 309 with 128 bit keys [AES]) 311 o Mode of operation (e.g., AES with Counter with Cipher Block 312 Chaining - Message Authentication Code (CBC-MAC) Mode (CCM)) 313 [RFC3610] 315 o Hash Algorithm for Integrity Protection, such as the Secure Hash 316 Algorithm (SHA) in combination with Keyed-Hashing for Message 317 Authentication (HMAC) (see [RFC2104] and [RFC4634]) 319 o Hash Algorithm for use with the Pseudorandom Function (e.g., HMAC 320 with the SHA-256) 322 o Misc information (e.g., length of authentication tags) 324 o Information whether the ciphersuite is suitable for DTLS or only 325 for TLS 327 The TLS ciphersuite TLS_PSK_WITH_AES_128_CCM_8, for example, uses a 328 pre-shared authentication and key exchange algorithm. RFC 6655 329 [RFC6655] defines this ciphersuite. It uses the Advanced Encryption 330 Standard (AES) encryption algorithm, which is a block cipher. Since 331 the AES algorithm supports different key lengths (such as 128, 192 332 and 256 bits) this information has to be specified as well and the 333 selected ciphersuite supports 128 bit keys. A block cipher encrypts 334 plaintext in fixed-size blocks and AES operates on fixed block size 335 of 128 bits. For messages exceeding 128 bits, the message is 336 partitioned into 128-bit blocks and the AES cipher is applied to 337 these input blocks with appropriate chaining, which is called mode of 338 operation. 340 TLS 1.2 introduced Authenticated Encryption with Associated Data 341 (AEAD) ciphersuites (see [RFC5116] and [RFC6655]). AEAD is a class 342 of block cipher modes which encrypt (parts of) the message and 343 authenticate the message simultaneously. Examples of such modes 344 include the Counter with Cipher Block Chaining - Message 345 Authentication Code (CBC-MAC) Mode (CCM) mode, and the Galois/Counter 346 Mode (GCM) (see [RFC5288] and [RFC7251]). 348 Some AEAD ciphersuites have shorter authentication tags and are 349 therefore more suitable for networks with low bandwidth where small 350 message size matters. The TLS_PSK_WITH_AES_128_CCM_8 ciphersuite 351 that ends in "_8" has an 8-octet authentication tag, while the 352 regular CCM ciphersuites have, at the time of writing, 16-octet 353 authentication tags. 355 TLS 1.2 also replaced the combination of MD5/SHA-1 hash functions in 356 the TLS pseudo random function (PRF) used in earlier versions of TLS 357 with cipher-suite-specified PRFs. For this reason authors of more 358 recent TLS 1.2 ciphersuite specifications explicitly indicate the MAC 359 algorithm and the hash functions used with the TLS PRF. 361 6. Credential Types 363 6.1. Pre-Shared Secret 365 The use of pre-shared secret credentials is one of the most basic 366 techniques for DTLS since it is both computational efficient and 367 bandwidth conserving. Pre-shared secret based authentication was 368 introduced to TLS with RFC 4279 [RFC4279]. The exchange shown in 369 Figure 2 illustrates the DTLS exchange including the cookie exchange. 370 While the server is not required to initiate a cookie exchange with 371 every handshake, the client is required to implement and to react on 372 it when challenged. The cookie exchange allows the server to react 373 to flooding attacks. 375 Client Server 376 ------ ------ 377 ClientHello --------> 379 <-------- HelloVerifyRequest 380 (contains cookie) 382 ClientHello --------> 383 (with cookie) 384 ServerHello 385 *ServerKeyExchange 386 <-------- ServerHelloDone 387 ClientKeyExchange 388 ChangeCipherSpec 389 Finished --------> 390 ChangeCipherSpec 391 <-------- Finished 393 Application Data <-------> Application Data 395 Legend: 397 * indicates an optional message payload 399 Figure 2: DTLS PSK Authentication including the Cookie Exchange. 401 [RFC4279] does not mandate the use of any particular type of 402 identity. Hence, the TLS client and server clearly have to agree on 403 the identities and keys to be used. The mandated encoding of 404 identities in Section 5.1 of RFC 4279 aims to improve 405 interoperability for those cases where the identity is configured by 406 a person using some management interface. Many IoT devices do, 407 however, not have a user interface and most of their credentials are 408 bound to the device rather than the user. Furthermore, credentials 409 are often provisioned into trusted hardware modules or in the 410 firmware by developers. As such, the encoding considerations are not 411 applicable to this usage environment. For use with this profile the 412 PSK identities SHOULD NOT assume a structured format (as domain 413 names, Distinguished Names, or IP addresses have) and a bit-by-bit 414 comparison operation can then be used by the server-side 415 infrastructure. 417 The client indicates which key it uses by including a "PSK identity" 418 in the ClientKeyExchange message. As described in Section 4 clients 419 may have multiple pre-shared keys with a single server and to help 420 the client in selecting which PSK identity / PSK pair to use, the 421 server can provide a "PSK identity hint" in the ServerKeyExchange 422 message. If the hint for PSK key selection is based on the domain 423 name of the server then servers SHOULD NOT send the "PSK identity 424 hint" in the ServerKeyExchange message. Hence, servers SHOULD NOT 425 send the "PSK identity hint" in the ServerKeyExchange message and 426 client MUST ignore the message. This approach is inline with RFC 427 4279 [RFC4279]. Note: The TLS Server Name Indication (SNI) extension 428 allows the client to tell a server the name of the server it is 429 contacting, which is relevant for hosting environments. A server 430 using the identity hint needs to guide the selection based on a 431 received SNI value from the client. 433 RFC 4279 requires TLS implementations supporting PSK ciphersuites to 434 support arbitrary PSK identities up to 128 octets in length, and 435 arbitrary PSKs up to 64 octets in length. This is a useful 436 assumption for TLS stacks used in the desktop and mobile environment 437 where management interfaces are used to provision identities and 438 keys. For the IoT environment, however, many devices are not 439 equipped with displays and input devices (e.g., keyboards). Hence, 440 keys are distributed as part of hardware modules or are embedded into 441 the firmware. As such, these restrictions are not applicable to this 442 profile. 444 Constrained Application Protocol (CoAP) [RFC7252] currently specifies 445 TLS_PSK_WITH_AES_128_CCM_8 as the mandatory to implement ciphersuite 446 for use with shared secrets. This ciphersuite uses the AES algorithm 447 with 128 bit keys and CCM as the mode of operation. The label "_8" 448 indicates that an 8-octet authentication tag is used. This 449 ciphersuite makes use of the default TLS 1.2 Pseudorandom Function 450 (PRF), which uses an HMAC with the SHA-256 hash function. (Note that 451 all IoT implementations will need a SHA-256 implementation due to the 452 construction of the pseudo-random number function in TLS 1.2.) 454 A device compliant with the profile in this section MUST implement 455 TLS_PSK_WITH_AES_128_CCM_8 and follow the guidance from this section. 457 6.2. Raw Public Key 459 The use of raw public keys with DTLS, as defined in [RFC7250], is the 460 first entry point into public key cryptography without having to pay 461 the price of certificates and a PKI. The specification re-uses the 462 existing Certificate message to convey the raw public key encoded in 463 the SubjectPublicKeyInfo structure. To indicate support two new TLS 464 extensions had been defined, as shown in Figure 3, namely the 465 server_certificate_type and the client_certificate_type. To operate 466 this mechanism securely it is necessary to authenticate and authorize 467 the public keys out-of-band. This document therefore assumes that a 468 client implementation comes with one or multiple raw public keys of 469 servers, it has to communicate with, pre-provisioned. Additionally, 470 a device will have its own raw public key. To replace, delete, or 471 add raw public key to this list requires a software update, for 472 example using a firmware update mechanism. 474 Client Server 475 ------ ------ 477 ClientHello --------> 478 client_certificate_type 479 server_certificate_type 481 <------- HelloVerifyRequest 483 ClientHello --------> 484 client_certificate_type 485 server_certificate_type 487 ServerHello 488 client_certificate_type 489 server_certificate_type 490 Certificate 491 ServerKeyExchange 492 CertificateRequest 493 <-------- ServerHelloDone 495 Certificate 496 ClientKeyExchange 497 CertificateVerify 498 [ChangeCipherSpec] 499 Finished --------> 501 [ChangeCipherSpec] 502 <-------- Finished 504 Figure 3: DTLS Raw Public Key Exchange including the Cookie Exchange. 506 The CoAP recommended ciphersuite for use with this credential type is 507 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. This elliptic curve 508 cryptography (ECC) based AES-CCM TLS ciphersuite uses the Ephemeral 509 Elliptic Curve Diffie-Hellman (ECDHE) as the key establishment 510 mechanism and an Elliptic Curve Digital Signature Algorithm (ECDSA) 511 for authentication. Due to the use of Ephemeral Elliptic Curve 512 Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman 513 groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this 514 profile. This ciphersuite make use of the AEAD capability in DTLS 515 1.2 and utilizes an eight-octet authentication tag. The use of a 516 Diffie-Hellman key exchange adds perfect forward secrecy (PFS). More 517 details about PFS can be found in Section 11. 519 RFC 6090 [RFC6090] provides valuable information for implementing 520 Elliptic Curve Cryptography algorithms, particularly for choosing 521 methods that have been available in the literature for a long time 522 (i.e., 20 years and more). 524 A device compliant with the profile in this section MUST implement 525 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 526 section. 528 6.3. Certificates 530 The use of mutual certificate-based authentication is shown in 531 Figure 4, which makes use of the cached info extension 532 [I-D.ietf-tls-cached-info]. Support of the cached info extension is 533 REQUIRED. Caching certificate chains allows the client to reduce the 534 communication overhead significantly since otherwise the server would 535 provide the end entity certificate, and the certificate chain. 536 Because certificate validation requires that root keys be distributed 537 independently, the self-signed certificate that specifies the root 538 certificate authority is omitted from the chain. Client 539 implementations MUST be provisioned with a trust anchor store that 540 contains the root certificates. The use of the Trust Anchor 541 Management Protocol (TAMP) [RFC5934] is, however, not envisioned. 542 Instead IoT devices using this profile MUST rely on a software update 543 mechanism to provision these trust anchors. 545 When DTLS is used to secure CoAP messages then the server provided 546 certificates MUST contain the fully qualified DNS domain name or 547 "FQDN" as dNSName. The coaps URI scheme is described in Section 6.2 548 of [RFC7252]. This FQDN is stored in the SubjectAltName or in the 549 leftmost CN component of subject name, as explained in 550 Section 9.1.3.3 of [RFC7252], and used by the client to match it 551 against the FQDN used during the look-up process, as described in RFC 552 6125 [RFC6125]. For the profile in this specification does not 553 assume dynamic discovery of local servers. 555 For client certificates the identifier used in the SubjectAltName or 556 in the CN MUST be an EUI-64 [EUI64], as mandated in Section 9.1.3.3 557 of [RFC7252]. 559 For certificate revocation neither the Online Certificate Status 560 Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used. 561 Instead, this profile relies on a software update mechanism. While 562 multiple OCSP stapling [RFC6961] has recently been introduced as a 563 mechanism to piggyback OCSP request/responses inside the DTLS/TLS 564 handshake to avoid the cost of a separate protocol handshake further 565 investigations are needed to determine its suitability for the IoT 566 environment. 568 Client Server 569 ------ ------ 571 ClientHello --------> 572 cached_information 574 <------- HelloVerifyRequest 576 ClientHello --------> 577 cached_information 578 ServerHello 579 cached_information 580 Certificate 581 ServerKeyExchange 582 CertificateRequest 583 <-------- ServerHelloDone 585 Certificate 586 ClientKeyExchange 587 CertificateVerify 588 [ChangeCipherSpec] 589 Finished --------> 591 [ChangeCipherSpec] 592 <-------- Finished 594 Figure 4: DTLS Mutual Certificate-based Authentication. 596 Regarding the ciphersuite choice the discussion in Section 6.2 597 applies. Further details about X.509 certificates can be found in 598 Section 9.1.3.3 of [RFC7252]. The TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 599 ciphersuite description in Section 6.2 is also applicable to this 600 section. 602 When using certificates, IoT devices MUST provide support for a 603 server certificate chain of at least 3 not including the trust anchor 604 and MAY reject connections from servers offering chains longer than 605 3. IoT devices MAY have client certificate chains of any length. 606 Obviously, longer chains require more resources to process, transmit 607 or receive. 609 A device compliant with the profile in this section MUST implement 610 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow the guidance from this 611 section. 613 6.3.1. Client Certificate URLs 615 RFC 6066 [RFC6066] allows to avoid sending client-side certificates 616 and uses URLs instead. This reduces the over-the-air transmission. 617 Note that the TLS cached info extension does not provide any help 618 with caching client certificates. 620 Recommendation: Add support for client certificate URLs for those 621 environments where client-side certificates are used. 623 6.3.2. Trusted CA Indication 625 RFC 6066 allows clients to indicate what trust anchor they support. 626 With certificate-based authentication a DTLS server conveys its end 627 entity certificate to the client during the DTLS exchange provides. 628 Since the server does not necessarily know what trust anchors the 629 client has stored it includes intermediate CA certs in the 630 certificate payload as well to facilitate with certification path 631 construction and path validation. 633 Today, in most IoT deployments there is a fairly static relationship 634 between the IoT device (and the software running on them) and the 635 server- side infrastructure and no such dynamic indication of trust 636 anchors is needed. 638 Recommendation: For IoT deployments where clients talk to a fixed, 639 pre-configured set of servers and where a software update mechanism 640 is available this extension is not recommended. Environments where 641 the client needs to interact with dynamically discovered DTLS servers 642 this extension may be useful to reduce the communication overhead. 643 Note, however, in that case the TLS cached info extension may help to 644 reduce the communication overhead for everything but the first 645 protocol interaction. 647 7. Signature Algorithm Extension 649 The "signature_algorithms" extension, defined in Section 7.4.1.4.1 of 650 RFC 5246 [RFC5246], allows the client to indicate to the server which 651 signature/hash algorithm pairs may be used in digital signatures. 652 The client MUST send this extension to select the use of SHA-256 653 since otherwise absent this extension RFC 5246 defaults to SHA-1 / 654 ECDSA for the ECDH_ECDSA and the ECDHE_ECDSA key exchange algorithms. 656 The "signature_algorithms" extension is not applicable to the PSK- 657 based ciphersuite described in Section 6.1. 659 8. Error Handling 661 DTLS uses the Alert protocol to convey error messages and specifies a 662 longer list of errors. However, not all error messages defined in 663 the TLS specification are applicable to this profile. In general, 664 there are two categories of errors (as defined in Section 7.2 of RFC 665 5246), namely fatal errors and warnings. Alert messages with a level 666 of fatal result in the immediate termination of the connection. If 667 possible, developers should try to develop strategies to react to 668 those fatal errors, such as re-starting the handshake or informing 669 the user using the (often limited) user interface. Warnings may be 670 ignored by the application since many IoT devices will either have 671 limited ways to log errors or no ability at all. In any case, 672 implementers have to carefully evaluate the impact of errors and ways 673 to remedy the situation since a commonly used approach for delegating 674 decision making to users is difficult (or impossible) to accomplish 675 in a timely fashion. 677 All error messages marked as RESERVED are only supported for 678 backwards compatibility with SSL and are therefore not applicable to 679 this profile. Those include decryption_failed_RESERVED, 680 no_certificate_RESERVE, and export_restriction_RESERVED. 682 A number of the error messages are applicable only for certificate- 683 based authentication ciphersuites. Hence, for PSK and raw public key 684 use the following error messages are not applicable: 686 o bad_certificate, 688 o unsupported_certificate, 690 o certificate_revoked, 692 o certificate_expired, 694 o certificate_unknown, 696 o unknown_ca, and 698 o access_denied. 700 Since this profile does not make use of compression at the TLS layer 701 the decompression_failure error message is not applicable either. 703 RFC 4279 introduced a new alert message unknown_psk_identity for PSK 704 ciphersuites. As stated in Section 2 of RFC 4279 the 705 decryption_error error message may also be used instead. For this 706 profile the TLS server MUST return the decryption_error error message 707 instead of the unknown_psk_identity. 709 Furthermore, the following errors should not occur with devices and 710 servers supporting this specification but implementations MUST be 711 prepared to process these errors to deal with servers that are not 712 compliant to the profiles in this document: 714 protocol_version: While this document focuses only on one version of 715 the DTLS protocol, namely version 1.2, ongoing work on TLS/DTLS 716 1.3 is taking place. 718 insufficient_security: This error message indicates that the server 719 requires ciphers to be more secure. This document specifies only 720 only one ciphersuite per profile but it is likely that additional 721 ciphtersuites get added over time. 723 user_canceled: Many IoT devices are unattended. 725 9. Session Resumption 727 Session resumption is a feature of DTLS that allows a client to 728 continue with an earlier established session state. The resulting 729 exchange is shown in Figure 5. In addition, the server may choose 730 not to do a cookie exchange when a session is resumed. Still, 731 clients have to be prepared to do a cookie exchange with every 732 handshake. 734 Client Server 735 ------ ------ 737 ClientHello --------> 738 ServerHello 739 [ChangeCipherSpec] 740 <-------- Finished 741 [ChangeCipherSpec] 742 Finished --------> 743 Application Data <-------> Application Data 745 Figure 5: DTLS Session Resumption. 747 Clients MUST implement session resumption to improve the performance 748 of the handshake (in terms of reduced number of message exchanges, 749 lower computational overhead, and less bandwidth conserved). 751 Since the communication model described in Section 4 does not assume 752 that the server is constrained RFC 5077 [RFC5077] specifying TLS 753 session resumption without server-side state is not utilized by this 754 profile. 756 10. Compression 758 [I-D.ietf-uta-tls-bcp] recommends to always disable DTLS-level 759 compression due to attacks. For IoT applications compression at the 760 DTLS is not needed since application layer protocols are highly 761 optimized and the compression algorithms at the DTLS layer increase 762 code size and complexity. 764 This DTLS client profile does not include DTLS layer compression. 766 11. Perfect Forward Secrecy 768 Perfect forward secrecy (PFS) is a property that preserves the 769 confidentiality of past conversations even in situations where the 770 long-term secret is compromised. 772 The PSK ciphersuite recommended in Section 6.1 does not offer this 773 property since it does not utilize a Diffie-Hellman exchange. New 774 ciphersuites that support PFS for PSK-based authentication, such as 775 proposed in [I-D.schmertmann-dice-ccm-psk-pfs], might become 776 available as standardized ciphersuite in the (near) future. 778 The use of PFS is a trade-off decision since on one hand the 779 compromise of long-term secrets of embedded devices is more likely 780 than with many other Internet hosts but on the other hand a Diffie- 781 Hellman exchange requires ephemeral key pairs to be generated, which 782 is demanding from a performance point of view. For performance 783 reasons some implementations re-use key pairs over multiple exchanges 784 (rather than generating new keys for each exchange) for the obvious 785 performance improvement. Note, however, that such key re-use over 786 long periods voids the benefits of forward secrecy when an attack 787 gains access to this DH key pair. 789 The impact of the disclosure of past conversations and the desire to 790 increase the cost for pervasive monitoring (as demanded by [RFC7258]) 791 has to be taken into account when making a deployment decision. 793 This specification recommends the use of the ciphersuites listed in 794 Section 6. 796 12. Keep-Alive 798 RFC 6520 [RFC6520] defines a heartbeat mechanism to test whether the 799 other peer is still alive. The same mechanism can also be used to 800 perform Path Maximum Transmission Unit (MTU) Discovery. 802 A recommendation about the use of RFC 6520 depends on the type of 803 message exchange an IoT device performs. There are three types of 804 exchanges that need to be analysed: 806 Client-Initiated, One-Shot Messages 808 This is a common communication pattern where IoT devices upload 809 data to a server on the Internet on an irregular basis. The 810 communication may be triggered by specific events, such as opening 811 a door. 813 Since the upload happens on an irregular and unpredictable basis 814 and due to renumbering and Network Address Translation (NAT) a new 815 DTLS session or DTLS session resumption can be used. 817 In this case there is no use for a keep-alive extension for this 818 scenario. 820 Client-Initiated, Regular Data Uploads 822 This is a variation of the previous case whereby data gets 823 uploaded on a regular basis, for example, based on frequent 824 temperature readings. If neither NAT bindings nor IP address 825 changes occurred then the DTLS record layer will not notice any 826 changes. For the case where the IP address and port number 827 changes, it is necessary to re-create the DTLS record layer using 828 session resumption. 830 In this scenario there is no use for a keep-alive extension. It 831 is also very likely that the device will enter a sleep cycle in 832 between data transmissions to keep power consumption low. 834 Server-Initiated Messages 836 In the two previous scenarios the client initiated the protocol 837 interaction but in this case we consider server-initiated 838 messages. Since messages to the client may get blocked by 839 intermediaries, such as NATs (including IPv4/IPv6 protocol 840 translators) and stateful packet filtering firewalls, the initial 841 connection setup is triggered by the client and then kept alive. 842 Since state at middleboxes expires fairly quickly (according to 843 measurements described in [HomeGateway]), regular heartbeats are 844 necessary whereby these keep-alive messages may be exchanged at 845 the application layer or within DTLS itself. 847 For this message exchange pattern the use of DTLS heartbeat 848 messages is quite useful. The MTU discovery mechanism, which is 849 also part of [RFC6520], is less likely to be relevant since for 850 many IoT deployments the most constrained link is the wireless 851 interface between the IoT device and the network itself (rather 852 than some links along the end-to-end path). Only in more complex 853 network topologies, such as multi-hop mesh networks, the situation 854 is. 856 For server-initiated messages the heartbeat extension can be 857 RECOMMENDED. 859 13. Timeouts 861 To connect to the Internet a variety of wired and wireless 862 technologies are available. Many of the low power radio 863 technologies, such as IEEE 802.15.4 or Bluetooth Smart, only support 864 small frame sizes (e.g., 127 bytes in case of IEEE 802.15.4 as 865 explained in RFC 4919 [RFC4919]). Other radio technologies, such as 866 the Global System for Mobile Communications (GSM) using the short 867 messaging service (SMS) have similar constraints in terms of payload 868 sizes, such as 140 bytes without the optional segmentation and 869 reassembly scheme known as Concatenated SMS, but show higher latency. 871 The DTLS handshake protocol adds a fragmentation and reassembly 872 mechanism to the TLS handshake protocol since each DTLS record must 873 fit within a single transport layer datagram, as described in 874 Section 4.2.3 of [RFC6347]. Since handshake messages are potentially 875 bigger than the maximum record size, the mechanism fragments a 876 handshake message over a number of DTLS records, each of which can be 877 transmitted separately. 879 To deal with the unreliable message delivery provided by UDP, DTLS 880 adds timeouts and re-transmissions, as described in Section 4.2.4 of 881 [RFC6347]. Although the timeout values are implementation specific, 882 recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 883 initial timer value of 1 second and twice the value at each 884 retransmission up to no less than 60 seconds. Due to the nature of 885 some radio technologies, these values are too aggressive and lead to 886 spurious failures when messages in flight need longer. 888 Choosing appropriate timeout values is difficult with infrequent data 889 transmissions, changing network conditions, and large variance in 890 latency. This specification therefore RECOMMENDS an initial timer 891 value of 10 seconds with exponential back off up to no less then 60 892 seconds. 894 Note: If a round-trip time estimator (such as proposed in 895 [I-D.bormann-core-cocoa]) is available in the protocol stack of the 896 device, it could be used to dynamically update the setting of the 897 retransmit timeout. 899 Appendix A provides additional information for carrying DTLS over 900 SMS. 902 14. Random Number Generation 904 The DTLS protocol requires random numbers to be available during the 905 protocol run. For example, during the ClientHello and the 906 ServerHello exchange the client and the server exchange random 907 numbers. Also, the use of the Diffie-Hellman exchange requires 908 random numbers during the key pair generation. Special care has to 909 be paid when generating random numbers in embedded systems as many 910 entropy sources available on desktop operating systems or mobile 911 devices might be missing, as described in [Heninger]. Consequently, 912 if not enough time is given during system start time to fill the 913 entropy pool then the output might be predictable and repeatable, for 914 example leading to the same keys generated again and again. 916 Recommendation: IoT devices using DTLS MUST offer ways to generate 917 quality random numbers. Guidelines and requirements for random 918 number generation can be found in RFC 4086 [RFC4086]. 920 It is important to note that sources contributing to the randomness 921 pool on laptops, or desktop PCs are not available on many IoT device, 922 such as mouse movement, timing of keystrokes, air turbulence on the 923 movement of hard drive heads, etc. Other sources have to be found or 924 dedicated hardware has to be added. 926 The ClientHello and the ServerHello message contains the 'Random' 927 structure, which has two components: gmt_unix_time and a random 928 sequence of 28 random bytes. gmt_unix_time holds the current time 929 and date in standard UNIX 32-bit format (seconds since the midnight 930 starting Jan 1, 1970, GMT). [I-D.mathewson-no-gmtunixtime] argues 931 that the entire value the ClientHello.Random and ServerHello.Random 932 fields, including gmt_unix_time, should be set to a cryptographically 933 random sequence because of privacy concerns (fingerprinting). Since 934 many IoT devices do not have access to a real-time clock this 935 recommendation is even more relevant in the embedded systems 936 environment. 938 15. Truncated MAC Extension 940 The truncated MAC extension was introduced with RFC 6066 with the 941 goal to reduces the size of the MAC used at the Record Layer. This 942 extension was developed for TLS ciphersuites that used older modes of 943 operation where the MAC and the encryption operation was performed 944 independently. 946 For CoAP, however, the recommended ciphersuites use the newer 947 Authenticated Encryption with Associated Data (AEAD) construct, 948 namely the CBC-MAC mode (CCM) with eight-octet authentication tags. 949 Furthermore, the extension [RFC7366] introducing the encrypt-then-MAC 950 security mechanism (instead of the MAC-then-encrypt) is also not 951 applicable for this profile. 953 Recommendation: Since this profile only supports AEAD ciphersuites 954 this extension is not applicable. 956 16. Server Name Indication (SNI) 958 This RFC 6066 extension defines a mechanism for a client to tell a 959 TLS server the name of the server it wants to contact. This is a 960 useful extension for many hosting environments where multiple virtual 961 servers are run on single IP address. 963 Recommendation: Unless it is known that a DTLS client does not 964 interact with a server in a hosting environment that requires such an 965 extension we advice to offer support for the SNI extension in this 966 profile. 968 17. Maximum Fragment Length Negotiation 970 This RFC 6066 extension lowers the maximum fragment length support 971 needed for the Record Layer from 2^14 bytes to 2^9 bytes. 973 This is a very useful extension that allows the client to indicate to 974 the server how much maximum memory buffers it uses for incoming 975 messages. Ultimately, the main benefit of this extension is it to 976 allows client implementations to lower their RAM requirements since 977 the client does not need to accept packets of large size (such as 16k 978 packets as required by plain TLS/DTLS). 980 Recommendation: Client implementations MUST support this extension. 982 18. TLS Session Hash 984 The TLS master secret is not cryptographically bound to important 985 session parameters such as the client and server identities. This 986 can be utilized by an attacker to mount a man-in-the-middle attack 987 since the master secret is not guaranteed to be unique across 988 sessions. 990 [I-D.ietf-tls-session-hash] defines a TLS extension that binds the 991 master secret to a log of the full handshake that computes it, thus 992 preventing such attacks. 994 Recommendation: Client implementations SHOULD implement this 995 extension even though the ciphersuites recommended by this profile 996 are not vulnerable to this attack. For Diffie-Hellman-based 997 ciphersuites the keying material is contributed by both parties and 998 in case of the pre-shared secret key ciphersuite both parties need to 999 be in possession of the shared secret to ensure that the handshake 1000 completes successfully. It is, however, possible that some 1001 application layer protocols will tunnel other authentication 1002 protocols on top of DTLS making this attack relevant again. 1004 19. Re-Negotiation Attacks 1006 TLS and DTLS allows a client and a server who already have a TLS 1007 connection to negotiate new parameters, generate new keys, etc by 1008 using a feature in TLS called re-negotiation. Renegotiation happens 1009 in the existing TLS connection, with the new handshake packets being 1010 encrypted along with application data. Upon completion of the re- 1011 negotiation procedure the new channel replaces the old channel. 1013 As described in RFC 5746 [RFC5746] there is no cryptographic binding 1014 between the two handshakes, although the new handshake is carried out 1015 using the cryptographic parameters established by the original 1016 handshake. 1018 To prevent the TLS re-negotiation attack [RFC5746] this specification 1019 RECOMMENDS not to use the TLS renegotigation feature. Clients MUST 1020 respond to server-initiated re-negotiation attempts with an Alert 1021 message (no_renegotiation) and clients MUST NOT initiate them. 1023 20. Downgrading Attacks 1025 [Editor's Note: Additional text needed.] 1027 This specification demands version 1.2 of DTLS to be used and DTLS 1028 version 1.1 is not supported. Unlike with TLS where many earlier 1029 versions exist there is no risk of downgrading to an older version of 1030 DTLS in context of this profile. The work described in 1031 [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to 1032 this environment since there is no legacy DTLS/TLS IoT server 1033 infrastructure when this profiled is followed. 1035 21. Crypto Agility 1037 This document recommends software and chip manufacturers to implement 1038 AES and the CCM mode of operation. This document references the CoAP 1039 recommended ciphersuite choices, which have been selected based on 1040 implementation and deployment experience from the IoT community. 1041 Over time the preference for algorithms will, however, change. Not 1042 all components of a ciphersuite are likely to change at the same 1043 speed. Changes are more likely expected for ciphers, the mode of 1044 operation, and the hash algorithms. The recommended key lengths have 1045 to be adjusted over time. Some deployment environments will also be 1046 impacted by local regulation, which might dictate a certain cipher 1047 and key size. Ongoing discussions regarding the choice of specific 1048 ECC curves will also likely to impact implementations. 1050 The following recommendations can be made to chip manufacturers: 1052 o Make any AES hardware-based crypto implementation accessible to 1053 developers working on security implementations at higher layers. 1054 Sometimes hardware implementatios are added to microcontrollers to 1055 offer support for functionality needed at the link layer and are 1056 only available to the on-chip link layer protocol implementation. 1058 o Provide flexibility for the use of the crypto function with future 1059 extensibility in mind. For example, making an AES-CCM 1060 implementation available to developers is a first step but such an 1061 implementation may not be usable due to parameter differences 1062 between an AES-CCM implementations. AES-CCM in IEEE 802.15.4 and 1063 Bluetooth Smart uses a nonce length of 13-octets while DTLS uses a 1064 nonce length of 12-octets. Hardware implementations of AES-CCM 1065 for IEEE 802.15.4 and Bluetooth Smart are therefore not re-usable 1066 by a DTLS stack. 1068 o Offer access to building blocks in addition (or as an alternative) 1069 to the complete functionality. For example, a chip manufacturer 1070 who gives developers access to an the AES crypto function can use 1071 it in functions to build an efficient AES-GCM implementations. 1072 Another example is to make a special instruction available that 1073 increases the speed of speed-up carryless multiplications. 1075 As a recommendation for developers and product architects we 1076 recommend that sufficient headroom is provided to allow an upgrade to 1077 a newer cryptographic algorithms over the lifetime of the product. 1079 As an example, while AES-CCM is recommended thoughout this 1080 specification future products might use the ChaCha20 cipher in 1081 combination with the Poly1305 authenticator 1082 [I-D.irtf-cfrg-chacha20-poly1305]. The assumption is made that a 1083 robust software update mechanism is offered. 1085 22. Key Length Recommendations 1087 RFC 4492 [RFC4492] gives approximate comparable key sizes for 1088 symmetric- and asymmetric-key cryptosystems based on the best-known 1089 algorithms for attacking them. While other publications suggest 1090 slightly different numbers, such as [Keylength], the approximate 1091 relationship still holds true. Figure 6 illustrates the comparable 1092 key sizes in bits. 1094 At the time of writing the key size recommendations for use with TLS- 1095 based ciphers found in [I-D.ietf-uta-tls-bcp] recommend DH key 1096 lengths of at least 2048 bit, which corresponds to a 112-bit 1097 symmetric key and a 233 bit ECC keys. These recommendations are 1098 inline with those from other organizations, such as National 1099 Institute of Standards and Technology (NIST) or European Network and 1100 Information Security Agency (ENISA). The authors of 1101 [ENISA-Report2013] add that a symmetric 80-bit security level is 1102 sufficient for legacy applications for the coming years, but a 1103 128-bit security level is the minimum requirement for new systems 1104 being deployed. The authors further note that one needs to also take 1105 into account the length of time data needs to be kept secure for. 1106 The use 80-bit encryption for transactional data may be acceptable 1107 for the near future while one has to insist on 128-bit encryption for 1108 long lived data. 1110 Symmetric | ECC | DH/DSA/RSA 1111 ------------+---------+------------- 1112 80 | 163 | 1024 1113 112 | 233 | 2048 1114 128 | 283 | 3072 1115 192 | 409 | 7680 1116 256 | 571 | 15360 1118 Figure 6: Comparable Key Sizes (in bits). 1120 23. TLS False Start 1122 A full TLS handshake as specified in [RFC5246] requires two full 1123 protocol rounds (four flights) before the handshake is complete and 1124 the protocol parties may begin to send application data. 1126 An abbreviated handshake (resuming an earlier TLS session) is 1127 complete after three flights, thus adding just one round-trip time if 1128 the client sends application data first. 1130 If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met, 1131 application data can be transmitted when the sender has sent its own 1132 "ChangeCipherSpec" and "Finished" messages. This achieves an 1133 improvement of one round-trip time for full handshakes if the client 1134 sends application data first, and for abbreviated handshakes if the 1135 server sends application data first. 1137 The conditions for using the TLS False Start mechanism are met by the 1138 public-key-based ciphersuites in this document. In summary, the 1139 conditions are 1141 o Modern symmetric ciphers with an effective key length of 128 bits, 1142 such as AES-128-CCM 1144 o Client certificate types, such as ecdsa_sign 1146 o Key exchange methods, such as ECDHE_ECDSA 1148 Based on the improvement over a full roundtrip for the full TLS/DTLS 1149 exchange this specification RECOMMENDS the use of the TLS False Start 1150 mechanism when clients send application data first. 1152 24. Privacy Considerations 1154 The DTLS handshake exchange conveys various identifiers, which can be 1155 observed by an on-path eavesdropper. For example, the DTLS PSK 1156 exchange reveals the PSK identity, the supported extensions, the 1157 session id, algorithm parameters, etc. When session resumption is 1158 used then individual TLS sessions can be correlated by an on-path 1159 adversary. With many IoT deployments it is likely that keying 1160 material and their identifiers are persistent over a longer period of 1161 time due to the cost of updating software on these devices. 1163 User participation with many IoT deployments poses a challenge since 1164 many of the IoT devices operate unattended, even though they will 1165 initially be provisioned by a human. The ability to control data 1166 sharing and to configure preference will have to be provided at a 1167 system level rather than at the level of the DTLS exchange itself, 1168 which is the scope of this document. Quite naturally, the use of 1169 DTLS with mutual authentication will allow a TLS server to collect 1170 authentication information about the IoT device (likely over a long 1171 period of time). While this strong form of authentication will 1172 prevent mis-attribution it also allows strong identification. 1173 Device-related data collection (e.g., sensor recordings) will be 1174 associated with other data to be truly useful and this extra data 1175 might include personal data about the owner of the device or data 1176 about the environment it senses. Consequently, the data stored on 1177 the server-side will be vulnerable to stored data compromise. For 1178 the communication between the client and the server this 1179 specification prevents eavesdroppers to gain access to the 1180 communication content. While the PSK-based ciphersuite does not 1181 provide PFS the asymmetric versions do. This prevents an adversary 1182 from obtaining past communication content when access to a long-term 1183 secret has been gained. Note that no extra effort to make traffic 1184 analysis more difficult is provided by the recommendations made in 1185 this document. 1187 25. Security Considerations 1189 This entire document is about security. 1191 We would also like to point out that designing a software update 1192 mechanism into an IoT system is crucial to ensure that both 1193 functionality can be enhanced and that potential vulnerabilities can 1194 be fixed. This software update mechanism is also useful for changing 1195 configuration information, for example, trust anchors and other 1196 keying related information. 1198 26. IANA Considerations 1200 This document includes no request to IANA. 1202 27. Acknowledgements 1204 Thanks to Paul Bakker, Robert Cragie, Russ Housley, Rene Hummen, 1205 Matthias Kovatsch, Sandeep Kumar, Sye Loong Keoh, Alexey Melnikov, 1206 Akbar Rahman, Eric Rescorla, Michael Richardson, Zach Shelby, Michael 1207 StJohns, Rene Struik, and Sean Turner for their helpful comments and 1208 discussions that have shaped the document. 1210 Big thanks also to Klaus Hartke, who wrote the initial version of 1211 this document. 1213 Finally, we would like to thank our area director (Stephen Farrell) 1214 and our working group chairs (Zach Shelby and Dorothy Gellert) for 1215 their support. 1217 28. References 1218 28.1. Normative References 1220 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1221 REGISTRATION AUTHORITY", April 2010, 1222 . 1225 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 1226 Partnership Project; Technical Specification Group Core 1227 Network and Terminals; Technical realization of the Short 1228 Message Service (SMS) (Release 7)", March 2007. 1230 [I-D.ietf-tls-cached-info] 1231 Santesson, S. and H. Tschofenig, "Transport Layer Security 1232 (TLS) Cached Information Extension", draft-ietf-tls- 1233 cached-info-17 (work in progress), November 2014. 1235 [I-D.ietf-tls-session-hash] 1236 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 1237 A., and M. Ray, "Transport Layer Security (TLS) Session 1238 Hash and Extended Master Secret Extension", draft-ietf- 1239 tls-session-hash-03 (work in progress), November 2014. 1241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, March 1997. 1244 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1245 for Transport Layer Security (TLS)", RFC 4279, December 1246 2005. 1248 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1249 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1251 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 1252 "Transport Layer Security (TLS) Renegotiation Indication 1253 Extension", RFC 5746, February 2010. 1255 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1256 Extension Definitions", RFC 6066, January 2011. 1258 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1259 Verification of Domain-Based Application Service Identity 1260 within Internet Public Key Infrastructure Using X.509 1261 (PKIX) Certificates in the Context of Transport Layer 1262 Security (TLS)", RFC 6125, March 2011. 1264 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1265 Security Version 1.2", RFC 6347, January 2012. 1267 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 1268 Layer Security (TLS) and Datagram Transport Layer Security 1269 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 1271 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 1272 T. Kivinen, "Using Raw Public Keys in Transport Layer 1273 Security (TLS) and Datagram Transport Layer Security 1274 (DTLS)", RFC 7250, June 2014. 1276 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 1277 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 1278 TLS", RFC 7251, June 2014. 1280 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 1281 Protocol", June 2001. 1283 28.2. Informative References 1285 [AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)", 1286 http://www.iana.org/assignments/tls-parameters/ 1287 tls-parameters.xhtml#tls-parameters-4, November 2001. 1289 [ENISA-Report2013] 1290 ENISA, "Algorithms, Key Sizes and Parameters Report - 1291 2013", http://www.enisa.europa.eu/activities/identity-and- 1292 trust/library/deliverables/ 1293 algorithms-key-sizes-and-parameters-report, October 2013. 1295 [Heninger] 1296 Heninger, N., Durumeric, Z., Wustrow, E., and A. 1297 Halderman, "Mining Your Ps and Qs: Detection of Widespread 1298 Weak Keys in Network Devices", 21st USENIX Security 1299 Symposium, 1300 https://www.usenix.org/conference/usenixsecurity12/ 1301 technical-sessions/presentation/heninger, 2012. 1303 [HomeGateway] 1304 Eggert, L., "An experimental study of home gateway 1305 characteristics, In Proceedings of the '10th annual 1306 conference on Internet measurement'", 2010. 1308 [I-D.bmoeller-tls-downgrade-scsv] 1309 Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1310 Suite Value (SCSV) for Preventing Protocol Downgrade 1311 Attacks", draft-bmoeller-tls-downgrade-scsv-02 (work in 1312 progress), May 2014. 1314 [I-D.bmoeller-tls-falsestart] 1315 Langley, A., Modadugu, N., and B. Moeller, "Transport 1316 Layer Security (TLS) False Start", draft-bmoeller-tls- 1317 falsestart-01 (work in progress), November 2014. 1319 [I-D.bormann-core-cocoa] 1320 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 1321 "CoAP Simple Congestion Control/Advanced", draft-bormann- 1322 core-cocoa-02 (work in progress), July 2014. 1324 [I-D.ietf-lwig-tls-minimal] 1325 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 1326 Guide to the (Datagram) Transport Layer Security Protocol 1327 for Smart Objects and Constrained Node Networks", draft- 1328 ietf-lwig-tls-minimal-01 (work in progress), March 2014. 1330 [I-D.ietf-tls-negotiated-dl-dhe] 1331 Gillmor, D., "Negotiated Discrete Log Diffie-Hellman 1332 Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- 1333 dl-dhe-00 (work in progress), July 2014. 1335 [I-D.ietf-tls-prohibiting-rc4] 1336 Popov, A., "Prohibiting RC4 Cipher Suites", draft-ietf- 1337 tls-prohibiting-rc4-01 (work in progress), October 2014. 1339 [I-D.ietf-uta-tls-bcp] 1340 Sheffer, Y., Holz, R., and P. Saint-Andre, 1341 "Recommendations for Secure Use of TLS and DTLS", draft- 1342 ietf-uta-tls-bcp-07 (work in progress), November 2014. 1344 [I-D.irtf-cfrg-chacha20-poly1305] 1345 Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1346 protocols", draft-irtf-cfrg-chacha20-poly1305-03 (work in 1347 progress), November 2014. 1349 [I-D.mathewson-no-gmtunixtime] 1350 Mathewson, N. and B. Laurie, "Deprecating gmt_unix_time in 1351 TLS", draft-mathewson-no-gmtunixtime-00 (work in 1352 progress), December 2013. 1354 [I-D.schmertmann-dice-ccm-psk-pfs] 1355 Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher 1356 Suites with Forward Secrecy for Transport Layer Security 1357 (TLS)", draft-schmertmann-dice-ccm-psk-pfs-01 (work in 1358 progress), August 2014. 1360 [IANA-TLS] 1361 IANA, "TLS Cipher Suite Registry", 1362 http://www.iana.org/assignments/tls-parameters/ 1363 tls-parameters.xhtml#tls-parameters-4, 2014. 1365 [Keylength] 1366 Giry, D., "Cryptographic Key Length Recommendations", 1367 http://www.keylength.com, November 2014. 1369 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1370 Hashing for Message Authentication", RFC 2104, February 1371 1997. 1373 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 1374 CBC-MAC (CCM)", RFC 3610, September 2003. 1376 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1377 Requirements for Security", BCP 106, RFC 4086, June 2005. 1379 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1380 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1381 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1383 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1384 (SHA and HMAC-SHA)", RFC 4634, July 2006. 1386 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1387 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1388 Overview, Assumptions, Problem Statement, and Goals", RFC 1389 4919, August 2007. 1391 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1392 "Transport Layer Security (TLS) Session Resumption without 1393 Server-Side State", RFC 5077, January 2008. 1395 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1396 Encryption", RFC 5116, January 2008. 1398 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1399 Housley, R., and W. Polk, "Internet X.509 Public Key 1400 Infrastructure Certificate and Certificate Revocation List 1401 (CRL) Profile", RFC 5280, May 2008. 1403 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 1404 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 1405 August 2008. 1407 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 1408 Management Protocol (TAMP)", RFC 5934, August 2010. 1410 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 1411 Curve Cryptography Algorithms", RFC 6090, February 2011. 1413 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1414 Transport Layer Security (TLS)", RFC 6655, July 2012. 1416 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1417 Multiple Certificate Status Request Extension", RFC 6961, 1418 June 2013. 1420 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1421 Constrained-Node Networks", RFC 7228, May 2014. 1423 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1424 Application Protocol (CoAP)", RFC 7252, June 2014. 1426 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1427 Attack", BCP 188, RFC 7258, May 2014. 1429 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1430 Security (TLS) and Datagram Transport Layer Security 1431 (DTLS)", RFC 7366, September 2014. 1433 Appendix A. Conveying DTLS over SMS 1435 This section is normative for the use of DTLS over SMS. Timer 1436 recommendations are already outlined in Section 13 and also 1437 applicable to the transport of DTLS over SMS. 1439 This section requires readers to be familiar with the terminology and 1440 concepts described in [GSM-SMS], and [WAP-WDP]. 1442 The remainder of this section assumes Mobile Stations are capable of 1443 producing and consuming 8-bit binary data encoded Transport Protocol 1444 Data Units (TPDU). 1446 A.1. Overview 1448 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 1449 serve as a return-routability test for protection against certain 1450 types of DoS attacks. Thus a full blown DTLS handshake comprises up 1451 to 6 "flights" (i.e., logical message exchanges), each of which is 1452 then mapped on to one or more DTLS records using the segmentation and 1453 reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The 1454 overhead for said scheme is 6 bytes per Handshake message which, 1455 given a realistic 10+ messages handshake, would amount around 60 1456 bytes across the whole handshake sequence. 1458 Note that the DTLS SaR scheme is defined for handshake messages only. 1459 In fact, DTLS records are never fragmented and MUST fit within a 1460 single transport layer datagram. 1462 SMS provides an optional segmentation and reassembly scheme as well, 1463 known as Concatenated short messages (see Section 9.2.3.24.1 of 1464 [GSM-SMS]). However, since the SaR scheme in DTLS cannot be 1465 circumvented, the Concatenated short messages mechanism SHOULD NOT be 1466 used during handshake to avoid redundant overhead. Before starting 1467 the handshake phase (either actively or passively), the DTLS 1468 implementation MUST be explicitly configured with the PMTU of the SMS 1469 transport in order to correctly instrument its SaR function. The 1470 PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see 1471 Appendix A.3), 140 bytes otherwise. 1473 It is RECOMMENDED to use the established security context over the 1474 longest possible period (possibly until a Closure Alert message is 1475 received, or after a very long inactivity timeout) to avoid the 1476 expensive re-establishment of the security association. 1478 A.2. Message Segmentation and Re-Assembly 1480 The content of an SMS message is carried in the TP-UserData field, 1481 and its size may be up to 140 bytes. As already mentioned in 1482 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent 1483 using Concatenated SMS. 1485 This scheme consumes 6-7 bytes (depending on whether the short or 1486 long segmentation format is used) of the TP-UserData field, thus 1487 reducing the space available for the actual content of the SMS 1488 message to 133-134 bytes per TPDU. 1490 Though in principle a PMTU value higher than 140 bytes could be used, 1491 which may look like an appealing option given its more efficient use 1492 of the transport, there are disadvantages to consider. First, there 1493 is an additional overhead of 7 bytes per TPDU to be paid to the SaR 1494 function (which is in addition to the overhead introduced by the DTLS 1495 SaR mechanism. Second, some networks only partially support the 1496 Concatenated SMS function and others do not support it at all. 1498 For these reasons, the Concatenated short messages mechanism SHOULD 1499 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 1500 used during the handshake phase, i.e., 133 bytes if WDP- based 1501 multiplexing is enabled, 140 bytes otherwise. 1503 Note that, after DTLS handshake has completed, any fragmentation and 1504 reassembly logic that pertains the application layer (e.g., 1505 segmenting CoAP messages into DTLS records and reassembling them 1506 after the crypto operations have been successfully performed) needs 1507 to be handled by the application that uses the established DTLS 1508 tunnel. 1510 A.3. Multiplexing Security Associations 1512 Unlike IPsec ESP/AH, DTLS records do not contain any association 1513 identifiers. Applications must arrange to multiplex between 1514 associations on the same endpoint which, when using UDP/IP, is 1515 usually done with the host/port number. 1517 If the DTLS server allows more than one client to be active at any 1518 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 1519 to achieve multiplexing of the different security associations. (The 1520 use of WDP provides the additional benefit that upper layer protocols 1521 can operate independently of the underlying wireless network, hence 1522 achieving application-agnostic transport handover.) 1524 The total overhead cost for encoding the WDP source and destination 1525 ports is 7 bytes out of the total available for the SMS content. 1527 The receiving side of the communication gets the source address from 1528 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 1529 way an unique 4-tuple identifying the security association can be 1530 reconstructed at both ends. (When replying to its DTLS peer, the 1531 sender will swaps the TP-OA and TP-DA parameters and the source and 1532 destination ports in the WDP.) 1534 A.4. Timeout 1536 If SMS-STATUS-REPORT messages are enabled, their receipt is not to be 1537 interpreted as the signal that the specific handshake message has 1538 been acted upon by the receiving party. Therefore, it MUST NOT be 1539 taken into account by the DTLS timeout and retransmission function. 1541 Handshake messages MUST carry a validity period (TP-VP parameter in a 1542 SMS-SUBMIT TPDU) that is not less than the current value of the 1543 retransmission timeout. In order to avoid persisting messages in the 1544 network that will be discarded by the receiving party, handshake 1545 messages SHOULD carry a validity period that is the same as, or just 1546 slightly higher than, the current value of the retransmission 1547 timeout. 1549 Authors' Addresses 1551 Hannes Tschofenig (editor) 1552 ARM Ltd. 1553 110 Fulbourn Rd 1554 Cambridge CB1 9NJ 1555 Great Britain 1557 Email: Hannes.tschofenig@gmx.net 1558 URI: http://www.tschofenig.priv.at 1560 Thomas Fossati 1561 Alcatel-Lucent 1562 3 Ely Road 1563 Milton, Cambridge CB24 6DD 1564 UK 1566 Email: thomas.fossati@alcatel-lucent.com