idnits 2.17.1 draft-ietf-uta-tls13-iot-profile-01.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 date (22 February 2021) is 1159 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) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-40 == Outdated reference: A later version (-16) exists of draft-ietf-suit-architecture-15 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-09 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA H. Tschofenig 3 Internet-Draft T. Fossati 4 Updates: 7925 (if approved) Arm Limited 5 Intended status: Standards Track 22 February 2021 6 Expires: 26 August 2021 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-ietf-uta-tls13-iot-profile-01 11 Abstract 13 This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 14 profiles for Internet of Things devices. It also updates RFC 7925 15 with regards to the X.509 certificate profile. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Source for this draft and an issue tracker can be found at 22 https://github.com/thomas-fossati/draft-tls13-iot 23 (https://github.com/thomas-fossati/draft-tls13-iot). 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 26 August 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 60 2. Credential Types . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Session Resumption . . . . . . . . . . . . . . . . . . . . . 4 63 5. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 4 65 7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 9. Random Number Generation . . . . . . . . . . . . . . . . . . 5 68 10. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 5 69 11. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 5 70 12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 5 71 13. Key Length Recommendations . . . . . . . . . . . . . . . . . 5 72 14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 6 74 15.1. All Certificates . . . . . . . . . . . . . . . . . . . . 6 75 15.1.1. Version . . . . . . . . . . . . . . . . . . . . . . 6 76 15.1.2. Serial Number . . . . . . . . . . . . . . . . . . . 6 77 15.1.3. Signature . . . . . . . . . . . . . . . . . . . . . 6 78 15.1.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . 6 79 15.1.5. Validity . . . . . . . . . . . . . . . . . . . . . . 7 80 15.1.6. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 7 81 15.2. Root CA Certificate . . . . . . . . . . . . . . . . . . 7 82 15.3. Intermediate CA Certificate . . . . . . . . . . . . . . 7 83 15.4. End Entity Certificate . . . . . . . . . . . . . . . . . 7 84 15.4.1. Client Certificate Subject . . . . . . . . . . . . . 8 85 16. Certificate Revocation Checks . . . . . . . . . . . . . . . . 8 86 16.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . 8 87 17. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 89 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 20.1. Normative References . . . . . . . . . . . . . . . . . . 9 92 20.2. Informative References . . . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 95 1. Introduction 97 This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and 98 TLS 1.3 [RFC8446] that offers communication security services for IoT 99 applications and is reasonably implementable on many constrained 100 devices. Profile thereby means that available configuration options 101 and protocol extensions are utilized to best support the IoT 102 environment. 104 For IoT profiles using TLS/DTLS 1.2 please consult [RFC7925]. This 105 document re-uses the communication pattern defined in [RFC7925] and 106 makes IoT-domain specific recommendations for version 1.3 (where 107 necessary). 109 TLS 1.3 has been re-designed and several previously defined 110 extensions are not applicable to the new version of TLS/DTLS anymore. 111 This clean-up also simplifies this document. Furthermore, many 112 outdated ciphersuites have been omitted from the TLS/DTLS 1.3 113 specification. 115 1.1. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Credential Types 125 In accordance with the recommendations in [RFC7925], a compliant 126 implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD 127 implement TLS_CHACHA20_POLY1305_SHA256. 129 Pre-shared key based authentication is integrated into the main TLS/ 130 DTLS 1.3 specification and has been harmonized with session 131 resumption. 133 A compliant implementation supporting authentication based on 134 certificates and raw public keys MUST support digital signatures with 135 ecdsa_secp256r1_sha256. A compliant implementation MUST support the 136 key exchange with secp256r1 (NIST P-256) and SHOULD support key 137 exchange with X25519. 139 A plain PSK-based TLS/DTLS client or server MUST implement the 140 following extensions: 142 * supported_versions 143 * cookie 144 * server_name 145 * pre_shared_key 146 * psk_key_exchange_modes 148 For TLS/DTLS clients and servers implementing raw public keys and/or 149 certificates the guidance for mandatory-to-implement extensions 150 described in Section 9.2 of [RFC8446] MUST be followed. 152 3. Error Handling 154 TLS 1.3 simplified the Alert protocol but the underlying challenge in 155 an embedded context remains unchanged, namely what should an IoT 156 device do when it encounters an error situation. The classical 157 approach used in a desktop environment where the user is prompted is 158 often not applicable with unattended devices. Hence, it is more 159 important for a developer to find out from which error cases a device 160 can recover from. 162 4. Session Resumption 164 TLS 1.3 has built-in support for session resumption by utilizing PSK- 165 based credentials established in an earlier exchange. 167 5. Compression 169 TLS 1.3 does not have support for compression. 171 6. Perfect Forward Secrecy 173 TLS 1.3 allows the use of PFS with all ciphersuites since the support 174 for it is negotiated independently. 176 7. Keep-Alive 178 The discussion in Section 10 of [RFC7925] is applicable. 180 8. Timeouts 182 The recommendation in Section 11 of [RFC7925] is applicable. In 183 particular this document RECOMMENDED to use an initial timer value of 184 9 seconds with exponential back off up to no less then 60 seconds. 186 Question: DTLS 1.3 now offers per-record retransmission and therefore 187 introduces much less congestion risk associated with spurious 188 retransmissions. Hence, should we relax the 9s initial timeout? 190 9. Random Number Generation 192 The discussion in Section 12 of [RFC7925] is applicable with one 193 exception: the ClientHello and the ServerHello messages in TLS 1.3 do 194 not contain gmt_unix_time component anymore. 196 10. Server Name Indication (SNI) 198 This specification mandates the implementation of the SNI extension. 199 Where privacy requirements require it, the encrypted SNI extension 200 [I-D.ietf-tls-esni] prevents an on-path attacker to determine the 201 domain name the client is trying to connect to. Note, however, that 202 the extension is still at an experimental state. 204 11. Maximum Fragment Length Negotiation 206 The Maximum Fragment Length Negotiation (MFL) extension has been 207 superseded by the Record Size Limit (RSL) extension [RFC8449]. 208 Implementations in compliance with this specification MUST implement 209 the RSL extension and SHOULD use it to indicate their RAM 210 limitations. 212 12. Crypto Agility 214 The recommendations in Section 19 of [RFC7925] are applicable. 216 13. Key Length Recommendations 218 The recommendations in Section 20 of [RFC7925] are applicable. 220 14. 0-RTT Data 222 When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to 223 send data on the first flight ("early data"). This features reduces 224 communication setup latency but requires application layer protocols 225 to define its use with the 0-RTT data functionality. 227 For HTTP this functionality is described in [RFC8470]. This document 228 specifies the application profile for CoAP, which follows the design 229 of [RFC8470]. 231 For a given request, the level of tolerance to replay risk is 232 specific to the resource it operates upon (and therefore only known 233 to the origin server). In general, if processing a request does not 234 have state-changing side effects, the consequences of replay are not 235 significant. The server can choose whether it will process early 236 data before the TLS handshake completes. 238 It is RECOMMENDED that origin servers allow resources to explicitly 239 configure whether early data is appropriate in requests. 241 This specification specifies the Early-Data option, which indicates 242 that the request has been conveyed in early data and that a client 243 understands the 4.25 (Too Early) status code. The semantic follows 244 [RFC8470]. 246 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 247 | No. | C | U | N | R | Name | Format | Length | Default | E | 248 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 249 | TBD | x | | | | Early-Data | empty | 0 | (none) | x | 250 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 252 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 253 E=Encrypt and Integrity Protect (when using OSCORE) 255 Figure 1: Early-Data Option 257 15. Certificate Profile 259 This section contains updates and clarifications to the certificate 260 profile defined in [RFC7925]. The content of Table 1 of [RFC7925] 261 has been split by certificate "type" in order to clarify exactly what 262 requirements and recommendations apply to which entity in the PKI 263 hierarchy. 265 15.1. All Certificates 267 15.1.1. Version 269 Certificates MUST be of type X.509 v3. 271 15.1.2. Serial Number 273 CAs SHALL generate non-sequential Certificate serial numbers greater 274 than zero (0) containing at least 64 bits of output from a CSPRNG 275 (cryptographically secure pseudo-random number generator). 277 15.1.3. Signature 279 The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. 281 15.1.4. Issuer 283 Contains the DN of the issuing CA. 285 15.1.5. Validity 287 No maximum validity period is mandated. Validity values are 288 expressed as UTCTime in notBefore and notAfter fields, as mandated in 289 [RFC5280]. 291 In many cases it is necessary to indicate that a certificate does not 292 expire. This is likely to be the case for manufacturer-provisioned 293 certificates. RFC 5280 provides a simple solution to convey the fact 294 that a certificate has no well-defined expiration date by setting the 295 notAfter to the GeneralizedTime value of 99991231235959Z. 297 Some devices might not have a reliable source of time and for those 298 devices it is also advisable to use certificates with no expiration 299 date and to let a device management solution manage the lifetime of 300 all the certificates used by the device. While this approach does 301 not utilize certificates to its widest extent, it is a solution that 302 extends the capabilities offered by a raw public key approach. 304 15.1.6. subjectPublicKeyInfo 306 The SubjectPublicKeyInfo structure indicates the algorithm and any 307 associated parameters for the ECC public key. This profile uses the 308 id-ecPublicKey algorithm identifier for ECDSA signature keys, as 309 defined and specified in [RFC5480]. 311 15.2. Root CA Certificate 313 * basicConstraints MUST be present and MUST be marked critical. The 314 cA field MUST be set true. The pathLenConstraint field SHOULD NOT 315 be present. 316 * keyUsage MUST be present and MUST be marked critical. Bit 317 position for keyCertSign MUST be set. 318 * extendedKeyUsage MUST NOT be present. 320 15.3. Intermediate CA Certificate 322 * basicConstraints MUST be present and MUST be marked critical. The 323 cA field MUST be set true. The pathLenConstraint field MAY be 324 present. 325 * keyUsage MUST be present and MUST be marked critical. Bit 326 position for keyCertSign MUST be set. 327 * extendedKeyUsage MUST NOT be present. 329 15.4. End Entity Certificate 331 * extendedKeyUsage MUST be present and contain at least one of id- 332 kp-serverAuth or id-kp-clientAuth. 334 * keyUsage MAY be present and contain one of digitalSignature or 335 keyAgreement. 336 * Domain names MUST NOT be encoded in the subject commonName, 337 instead they MUST be encoded in a subjectAltName of type DNS-ID. 338 Domain names MUST NOT contain wildcard ("*") characters. 339 subjectAltName MUST NOT contain multiple names. 341 15.4.1. Client Certificate Subject 343 The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for 344 client certificates is lifted. 346 If the EUI-64 format is used to identify the subject of a client 347 certificate, it MUST be encoded in a subjectAltName of type DNS-ID as 348 a string of the form "HH-HH-HH-HH-HH-HH-HH-HH" where 'H' is one of 349 the symbols '0'-'9' or 'A'-'F'. 351 16. Certificate Revocation Checks 353 The considerations in Section 4.4.3 of [RFC7925] hold. 355 Since the publication of RFC 7925 the need for firmware update 356 mechanisms has been reinforced and the work on standardizing a secure 357 and interoperable firmware update mechanism has made substantial 358 progress, see [I-D.ietf-suit-architecture]. RFC 7925 recommends to 359 use a software / firmware update mechanism to provision devices with 360 new trust anchors. 362 The use of device management protocols for IoT devices, which often 363 include an onboarding or bootstrapping mechanism, has also seen 364 considerable uptake in deployed devices and these protocols, some of 365 which are standardized, allow provision of certificates on a regular 366 basis. This enables a deployment model where IoT device utilize end- 367 entity certificates with shorter lifetime making certificate 368 revocation protocols, like OCSP and CRLs, less relevant. 370 Hence, instead of performing certificate revocation checks on the IoT 371 device itself this specification recommends to delegate this task to 372 the IoT device operator and to take the necessary action to allow IoT 373 devices to remain operational. 375 16.1. Open Issues 377 A list of open issues can be found at https://github.com/thomas- 378 fossati/draft-tls13-iot/issues 380 17. Security Considerations 382 This entire document is about security. 384 18. Acknowledgements 386 We would like to thank Ben Kaduk and John Mattsson. 388 19. IANA Considerations 390 IANA is asked to add the Option defined in Figure 2 to the CoAP 391 Option Numbers registry. 393 +--------+------------+-----------+ 394 | Number | Name | Reference | 395 +--------+------------+-----------+ 396 | TBD | Early-Data | RFCThis | 397 +--------+------------+-----------+ 399 Figure 2: Early-Data Option 401 IANA is asked to add the Response Code defined in Figure 3 to the 402 CoAP Response Code registry. 404 +--------+-------------+-----------+ 405 | Code | Description | Reference | 406 +--------+-------------+-----------+ 407 | 4.25 | Too Early | RFCThis | 408 +--------+-------------+-----------+ 410 Figure 3: Too Early Response Code 412 20. References 414 20.1. Normative References 416 [I-D.ietf-tls-dtls13] 417 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 418 Datagram Transport Layer Security (DTLS) Protocol Version 419 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 420 dtls13-40, 20 January 2021, . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 429 Housley, R., and W. Polk, "Internet X.509 Public Key 430 Infrastructure Certificate and Certificate Revocation List 431 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 432 . 434 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 435 "Elliptic Curve Cryptography Subject Public Key 436 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 437 . 439 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 440 Polk, "Internet X.509 Public Key Infrastructure: 441 Additional Algorithms and Identifiers for DSA and ECDSA", 442 RFC 5758, DOI 10.17487/RFC5758, January 2010, 443 . 445 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 446 Security (TLS) / Datagram Transport Layer Security (DTLS) 447 Profiles for the Internet of Things", RFC 7925, 448 DOI 10.17487/RFC7925, July 2016, 449 . 451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 453 May 2017, . 455 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 456 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 457 . 459 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 460 RFC 8449, DOI 10.17487/RFC8449, August 2018, 461 . 463 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 464 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 465 2018, . 467 20.2. Informative References 469 [I-D.ietf-suit-architecture] 470 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 471 Firmware Update Architecture for Internet of Things", Work 472 in Progress, Internet-Draft, draft-ietf-suit-architecture- 473 15, 17 January 2021, . 476 [I-D.ietf-tls-esni] 477 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 478 Encrypted Client Hello", Work in Progress, Internet-Draft, 479 draft-ietf-tls-esni-09, 16 December 2020, 480 . 483 Authors' Addresses 485 Hannes Tschofenig 486 Arm Limited 488 Email: Hannes.Tschofenig@gmx.net 490 Thomas Fossati 491 Arm Limited 493 Email: Thomas.Fossati@arm.com