idnits 2.17.1 draft-ietf-uta-tls13-iot-profile-00.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 (5 June 2020) is 1413 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-38 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 == Outdated reference: A later version (-08) exists of draft-mattsson-cose-cbor-cert-compress-00 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 5 June 2020 6 Expires: 7 December 2020 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-ietf-uta-tls13-iot-profile-00 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 7 December 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . 4 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. Compression . . . . . . . . . . . . . . . . . . . . . . 6 75 16. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 18.1. Normative References . . . . . . . . . . . . . . . . . . 7 79 18.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and 85 TLS 1.3 [RFC8446] that offers communication security services for IoT 86 applications and is reasonably implementable on many constrained 87 devices. Profile thereby means that available configuration options 88 and protocol extensions are utilized to best support the IoT 89 environment. 91 For IoT profiles using TLS/DTLS 1.2 please consult [RFC7925]. This 92 document re-uses the communication pattern defined in [RFC7925] and 93 makes IoT-domain specific recommendations for version 1.3 (where 94 necessary). 96 TLS 1.3 has been re-designed and several previously defined 97 extensions are not applicable to the new version of TLS/DTLS anymore. 98 This clean-up also simplifies this document. Furthermore, many 99 outdated ciphersuites have been omitted from the TLS/DTLS 1.3 100 specification. 102 1.1. Conventions and Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Credential Types 112 In accordance with the recommendations in [RFC7925], a compliant 113 implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD 114 implement TLS_CHACHA20_POLY1305_SHA256. 116 Pre-shared key based authentication is integrated into the main TLS/ 117 DTLS 1.3 specification and has been harmonized with session 118 resumption. 120 A compliant implementation supporting authentication based on 121 certificates and raw public keys MUST support digital signatures with 122 ecdsa_secp256r1_sha256. A compliant implementation MUST support the 123 key exchange with secp256r1 (NIST P-256) and SHOULD support key 124 exchange with X25519. 126 A plain PSK-based TLS/DTLS client or server MUST implement the 127 following extensions: 129 * supported_versions 130 * cookie 131 * server_name 132 * pre_shared_key 133 * psk_key_exchange_modes 135 For TLS/DTLS clients and servers implementing raw public keys and/or 136 certificates the guidance for mandatory-to-implement extensions 137 described in Section 9.2 of [RFC8446] MUST be followed. 139 3. Error Handling 141 TLS 1.3 simplified the Alert protocol but the underlying challenge in 142 an embedded context remains unchanged, namely what should an IoT 143 device do when it encounters an error situation. The classical 144 approach used in a desktop environment where the user is prompted is 145 often not applicable with unattended devices. Hence, it is more 146 important for a developer to find out from which error cases a device 147 can recover from. 149 4. Session Resumption 151 TLS 1.3 has built-in support for session resumption by utilizing PSK- 152 based credentials established in an earlier exchange. 154 5. Compression 156 TLS 1.3 does not have support for compression. 158 6. Perfect Forward Secrecy 160 TLS 1.3 allows the use of PFS with all ciphersuites since the support 161 for it is negotiated independently. 163 7. Keep-Alive 165 The discussion in Section 10 of [RFC7925] is applicable. 167 8. Timeouts 169 The recommendation in Section 11 of [RFC7925] is applicable. In 170 particular this document RECOMMENDED to use an initial timer value of 171 9 seconds with exponential back off up to no less then 60 seconds. 173 Question: DTLS 1.3 now offers per-record retransmission and therefore 174 introduces much less congestion risk associated with spurious 175 retransmissions. Hence, should we relax the 9s initial timeout? 177 9. Random Number Generation 179 The discussion in Section 12 of [RFC7925] is applicable with one 180 exception: the ClientHello and the ServerHello messages in TLS 1.3 do 181 not contain gmt_unix_time component anymore. 183 10. Server Name Indication (SNI) 185 This specification mandates the implementation of the SNI extension. 186 Where privacy requirements require it, the encrypted SNI extension 187 [I-D.ietf-tls-esni] prevents an on-path attacker to determine the 188 domain name the client is trying to connect to. Note, however, that 189 the extension is still at an experimental state. 191 11. Maximum Fragment Length Negotiation 193 The Maximum Fragment Length Negotiation (MFL) extension has been 194 superseded by the Record Size Limit (RSL) extension [RFC8449]. 195 Implementations in compliance with this specification MUST implement 196 the RSL extension and SHOULD use it to indicate their RAM 197 limitations. 199 12. Crypto Agility 201 The recommendations in Section 19 of [RFC7925] are applicable. 203 13. Key Length Recommendations 205 The recommendations in Section 20 of [RFC7925] are applicable. 207 14. 0-RTT Data 209 When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to 210 send data on the first flight ("early data"). This features reduces 211 communication setup latency but requires application layer protocols 212 to define its use with the 0-RTT data functionality. 214 For HTTP this functionality is described in [RFC8470]. This document 215 specifies the application profile for CoAP, which follows the design 216 of [RFC8470]. 218 For a given request, the level of tolerance to replay risk is 219 specific to the resource it operates upon (and therefore only known 220 to the origin server). In general, if processing a request does not 221 have state-changing side effects, the consequences of replay are not 222 significant. The server can choose whether it will process early 223 data before the TLS handshake completes. 225 It is RECOMMENDED that origin servers allow resources to explicitly 226 configure whether early data is appropriate in requests. 228 This specification specifies the Early-Data option, which indicates 229 that the request has been conveyed in early data and that a client 230 understands the 4.25 (Too Early) status code. The semantic follows 231 [RFC8470]. 233 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 234 | No. | C | U | N | R | Name | Format | Length | Default | E | 235 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 236 | TBD | x | | | | Early-Data | empty | 0 | (none) | x | 237 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 239 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 240 E=Encrypt and Integrity Protect (when using OSCORE) 242 Figure 1: Early-Data Option 244 15. Certificate Profile 246 This section is intended for discussing updates to the certificate 247 profile defined in [RFC7925]. Initial set of things to consider: 249 * pathLenConstraint 251 Question: should also we move the ASN.1 schema from Appendix B of 252 [I-D.raza-ace-cbor-certificates] here and let it have it by 253 reference? 255 15.1. Compression 257 The compression methods defined in 258 [I-D.ietf-tls-certificate-compression] do not seem to deal 259 effectively with [RFC7925] profiled certificates: zlib compresses the 260 example cert by 9%, but other certificates and compression algorithms 261 do in many cases increase the overall size. On the other hand, 262 [I-D.raza-ace-cbor-certificates] provides a more efficient scheme, 263 yielding to compression rates higher than 50% (see Section 3 of 264 [I-D.mattsson-cose-cbor-cert-compress]). 266 Question: should we RECOMMEND CBOR compression? How is that 267 negotiated? 269 16. Security Considerations 271 This entire document is about security. 273 17. IANA Considerations 275 IANA is asked to add the Option defined in Figure 2 to the CoAP 276 Option Numbers registry. 278 +--------+------------+-----------+ 279 | Number | Name | Reference | 280 +--------+------------+-----------+ 281 | TBD | Early-Data | RFCThis | 282 +--------+------------+-----------+ 284 Figure 2: Early-Data Option 286 IANA is asked to add the Response Code defined in Figure 3 to the 287 CoAP Response Code registry. 289 +--------+-------------+-----------+ 290 | Code | Description | Reference | 291 +--------+-------------+-----------+ 292 | 4.25 | Too Early | RFCThis | 293 +--------+-------------+-----------+ 295 Figure 3: Too Early Response Code 297 18. References 299 18.1. Normative References 301 [I-D.ietf-tls-dtls13] 302 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 303 Datagram Transport Layer Security (DTLS) Protocol Version 304 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 305 dtls13-38, 29 May 2020, . 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, 310 DOI 10.17487/RFC2119, March 1997, 311 . 313 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 314 Security (TLS) / Datagram Transport Layer Security (DTLS) 315 Profiles for the Internet of Things", RFC 7925, 316 DOI 10.17487/RFC7925, July 2016, 317 . 319 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 320 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 321 May 2017, . 323 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 324 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 325 . 327 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 328 RFC 8449, DOI 10.17487/RFC8449, August 2018, 329 . 331 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 332 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 333 2018, . 335 18.2. Informative References 337 [I-D.ietf-tls-certificate-compression] 338 Ghedini, A. and V. Vasiliev, "TLS Certificate 339 Compression", Work in Progress, Internet-Draft, draft- 340 ietf-tls-certificate-compression-10, 6 January 2020, 341 . 344 [I-D.ietf-tls-esni] 345 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 346 Encrypted Client Hello", Work in Progress, Internet-Draft, 347 draft-ietf-tls-esni-07, 1 June 2020, . 350 [I-D.mattsson-cose-cbor-cert-compress] 351 Mattsson, J., Selander, G., Raza, S., Hoglund, J., and M. 352 Furuhed, "CBOR Object Signing and Encryption (COSE): 353 Headers for Carrying CBOR Compressed Certificates", Work 354 in Progress, Internet-Draft, draft-mattsson-cose-cbor- 355 cert-compress-00, 9 March 2020, . 359 [I-D.raza-ace-cbor-certificates] 360 Raza, S., Hoglund, J., Selander, G., Mattsson, J., and M. 361 Furuhed, "CBOR Profile of X.509 Certificates", Work in 362 Progress, Internet-Draft, draft-raza-ace-cbor- 363 certificates-04, 9 March 2020, . 366 Authors' Addresses 368 Hannes Tschofenig 369 Arm Limited 371 Email: Hannes.Tschofenig@gmx.net 373 Thomas Fossati 374 Arm Limited 376 Email: Thomas.Fossati@arm.com