idnits 2.17.00 (12 Aug 2021) /tmp/idnits5405/draft-ietf-uta-tls13-iot-profile-04.txt: -(648): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (7 March 2022) is 68 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: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: A later version (-06) exists of draft-ietf-uta-rfc7525bis-05 == Outdated reference: draft-ietf-tls-dtls-connection-id has been published as RFC 9146 == Outdated reference: draft-ietf-suit-architecture has been published as RFC 9019 == Outdated reference: draft-ietf-tls-certificate-compression has been published as RFC 8879 == Outdated reference: A later version (-05) exists of draft-ietf-tls-ctls-04 == Outdated reference: A later version (-04) exists of draft-irtf-cfrg-aead-limits-03 == Outdated reference: draft-irtf-cfrg-hpke has been published as RFC 9180 Summary: 0 errors (**), 0 flaws (~~), 9 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 7 March 2022 6 Expires: 8 September 2022 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-ietf-uta-tls13-iot-profile-04 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. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 8 September 2022. 41 Copyright Notice 43 Copyright (c) 2022 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 3 59 2. Credential Types . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Session Resumption . . . . . . . . . . . . . . . . . . . . . 4 62 5. Compression . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5 64 7. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Random Number Generation . . . . . . . . . . . . . . . . . . 5 67 10. Server Name Indication . . . . . . . . . . . . . . . . . . . 5 68 11. Maximum Fragment Length Negotiation . . . . . . . . . . . . 5 69 12. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 6 70 13. Key Length Recommendations . . . . . . . . . . . . . . . . . 6 71 14. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 15. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 7 73 15.1. All Certificates . . . . . . . . . . . . . . . . . . . . 7 74 15.1.1. Version . . . . . . . . . . . . . . . . . . . . . . 7 75 15.1.2. Serial Number . . . . . . . . . . . . . . . . . . . 7 76 15.1.3. Signature . . . . . . . . . . . . . . . . . . . . . 7 77 15.1.4. Issuer . . . . . . . . . . . . . . . . . . . . . . . 7 78 15.1.5. Validity . . . . . . . . . . . . . . . . . . . . . 7 79 15.1.6. subjectPublicKeyInfo . . . . . . . . . . . . . . . 8 80 15.2. Root CA Certificate . . . . . . . . . . . . . . . . . . 8 81 15.3. Intermediate CA Certificate . . . . . . . . . . . . . . 8 82 15.4. End Entity Certificate . . . . . . . . . . . . . . . . . 8 83 15.4.1. Client Certificate Subject . . . . . . . . . . . . . 9 84 16. Certificate Revocation Checks . . . . . . . . . . . . . . . . 9 85 17. Certificate Overhead . . . . . . . . . . . . . . . . . . . . 9 86 18. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10 87 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 20. Security Considerations . . . . . . . . . . . . . . . . . . . 11 89 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 23.1. Normative References . . . . . . . . . . . . . . . . . . 12 93 23.2. Informative References . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 This document defines a profile of DTLS 1.3 [DTLS13] and TLS 1.3 99 [RFC8446] that offers communication security services for IoT 100 applications and is reasonably implementable on many constrained 101 devices. Profile thereby means that available configuration options 102 and protocol extensions are utilized to best support the IoT 103 environment. 105 For IoT profiles using TLS/DTLS 1.2 please consult [RFC7925]. This 106 document re-uses the communication pattern defined in [RFC7925] and 107 makes IoT-domain specific recommendations for version 1.3 (where 108 necessary). 110 TLS 1.3 has been re-designed and several previously defined 111 extensions are not applicable to the new version of TLS/DTLS anymore. 112 This clean-up also simplifies this document. Furthermore, many 113 outdated ciphersuites have been omitted from the TLS/DTLS 1.3 114 specification. 116 1.1. Conventions and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. Credential Types 126 In accordance with the recommendations in [RFC7925], a compliant 127 implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD 128 implement TLS_CHACHA20_POLY1305_SHA256. 130 Pre-shared key based authentication is integrated into the main TLS/ 131 DTLS 1.3 specification and has been harmonized with session 132 resumption. 134 A compliant implementation supporting authentication based on 135 certificates and raw public keys MUST support digital signatures with 136 ecdsa_secp256r1_sha256. A compliant implementation MUST support the 137 key exchange with secp256r1 (NIST P-256) and SHOULD support key 138 exchange with X25519. 140 A plain PSK-based TLS/DTLS client or server MUST implement the 141 following extensions: 143 * Supported Versions, 144 * Cookie, 145 * Server Name Indication (SNI), 146 * Pre-Shared Key, 147 * PSK Key Exchange Modes, and 148 * Application-Layer Protocol Negotiation (ALPN). 150 The SNI extension is discussed in this document and the justification 151 for implementing and using the ALPN extension can be found in 152 [RFC7525bis]. 154 For TLS/DTLS clients and servers implementing raw public keys and/or 155 certificates the guidance for mandatory-to-implement extensions 156 described in Section 9.2 of [RFC8446] MUST be followed. 158 3. Error Handling 160 TLS 1.3 simplified the Alert protocol but the underlying challenge in 161 an embedded context remains unchanged, namely what should an IoT 162 device do when it encounters an error situation. The classical 163 approach used in a desktop environment where the user is prompted is 164 often not applicable with unattended devices. Hence, it is more 165 important for a developer to find out from which error cases a device 166 can recover from. 168 4. Session Resumption 170 TLS 1.3 has built-in support for session resumption by utilizing PSK- 171 based credentials established in an earlier exchange. 173 5. Compression 175 TLS 1.3 does not have support for compression of application data 176 traffic, as offered by previous versions of TLS. Applications are 177 therefore responsible for transmitting payloads that are either 178 compressed or use a more efficient encoding otherwise. 180 With regards to the handshake itself, various strategies have been 181 applied to reduce the size of the exchanged payloads. TLS and DTLS 182 1.3 use less overhead, depending on the type of key confirmations, 183 when compared to previous versions of the protocol. Additionally, 184 the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken 185 compression of the handshake a step further by utilizing out-of-band 186 knowledge between the communication parties to reduce the amount of 187 data to be transmitted at each individual handshake, among applying 188 other techniques. 190 6. Perfect Forward Secrecy 192 TLS 1.3 allows the use of PFS with all ciphersuites since the support 193 for it is negotiated independently. 195 7. Keep-Alive 197 The discussion in Section 10 of [RFC7925] is applicable. 199 8. Timeouts 201 The recommendation in Section 11 of [RFC7925] is applicable. In 202 particular this document RECOMMENDED to use an initial timer value of 203 9 seconds with exponential back off up to no less then 60 seconds. 205 9. Random Number Generation 207 The discussion in Section 12 of [RFC7925] is applicable with one 208 exception: the ClientHello and the ServerHello messages in TLS 1.3 do 209 not contain gmt_unix_time component anymore. 211 10. Server Name Indication 213 This specification mandates the implementation of the Server Name 214 Indication (SNI) extension. Where privacy requirements require it, 215 the Encrypted Client Hello extension [I-D.ietf-tls-esni] prevents an 216 on-path attacker to determine the domain name the client is trying to 217 connect to. 219 Note: To avoid leaking DNS lookups from network inspection altogether 220 further protocols are needed, including DoH [RFC8484] and DPRIVE 221 [RFC7858] [RFC8094]. Since the Encrypted Client Hello extension 222 requires use of Hybrid Public Key Encryption (HPKE) 223 [I-D.irtf-cfrg-hpke] and additional protocols require further 224 protocol exchanges and cryptographic operations, there is a certain 225 amount of overhead associated with this privacy property. 227 11. Maximum Fragment Length Negotiation 229 The Maximum Fragment Length Negotiation (MFL) extension has been 230 superseded by the Record Size Limit (RSL) extension [RFC8449]. 231 Implementations in compliance with this specification MUST implement 232 the RSL extension and SHOULD use it to indicate their RAM 233 limitations. 235 12. Crypto Agility 237 The recommendations in Section 19 of [RFC7925] are applicable. 239 13. Key Length Recommendations 241 The recommendations in Section 20 of [RFC7925] are applicable. 243 14. 0-RTT Data 245 When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to 246 send data on the first flight ("early data"). This features reduces 247 communication setup latency but requires application layer protocols 248 to define its use with the 0-RTT data functionality. 250 For HTTP this functionality is described in [RFC8470]. This document 251 specifies the application profile for CoAP, which follows the design 252 of [RFC8470]. 254 For a given request, the level of tolerance to replay risk is 255 specific to the resource it operates upon (and therefore only known 256 to the origin server). In general, if processing a request does not 257 have state-changing side effects, the consequences of replay are not 258 significant. The server can choose whether it will process early 259 data before the TLS handshake completes. 261 It is RECOMMENDED that origin servers allow resources to explicitly 262 configure whether early data is appropriate in requests. 264 This document specifies the Early-Data option, which indicates that 265 the request has been conveyed in early data and that a client 266 understands the 4.25 (Too Early) status code. The semantic follows 267 [RFC8470]. 269 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 270 | No. | C | U | N | R | Name | Format | Length | Default | E | 271 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 272 | TBD | x | | | | Early-Data | empty | 0 | (none) | x | 273 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 275 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 276 E=Encrypt and Integrity Protect (when using OSCORE) 278 Figure 1: Early-Data Option 280 // Note that 4.25 is just the suggested CoAP response code, which has 281 // not been registered yet. 283 15. Certificate Profile 285 This section contains updates and clarifications to the certificate 286 profile defined in [RFC7925]. The content of Table 1 of [RFC7925] 287 has been split by certificate "type" in order to clarify exactly what 288 requirements and recommendations apply to which entity in the PKI 289 hierarchy. 291 15.1. All Certificates 293 15.1.1. Version 295 Certificates MUST be of type X.509 v3. 297 15.1.2. Serial Number 299 CAs SHALL generate non-sequential Certificate serial numbers greater 300 than zero (0) containing at least 64 bits of output from a CSPRNG 301 (cryptographically secure pseudo-random number generator). 303 15.1.3. Signature 305 The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. 307 15.1.4. Issuer 309 Contains the DN of the issuing CA. 311 15.1.5. Validity 313 No maximum validity period is mandated. Validity values are 314 expressed in notBefore and notAfter fields, as described in 315 Section 4.1.2.5 of [RFC5280]. In particular, values MUST be 316 expressed in Greenwich Mean Time (Zulu) and MUST include seconds even 317 where the number of seconds is zero. 319 Note that the validity period is defined as the period of time from 320 notBefore through notAfter, inclusive. This means that a 321 hypothetical certificate with a notBefore date of 9 June 2021 at 322 03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes 323 valid at the beginning of the :01 second, and only becomes invalid at 324 the :02 second, a period that is 90 days plus 1 second. So for a 325 90-day, notAfter must actually be 03:42:00. 327 In many cases it is necessary to indicate that a certificate does not 328 expire. This is likely to be the case for manufacturer-provisioned 329 certificates. RFC 5280 provides a simple solution to convey the fact 330 that a certificate has no well-defined expiration date by setting the 331 notAfter to the GeneralizedTime value of 99991231235959Z. 333 Some devices might not have a reliable source of time and for those 334 devices it is also advisable to use certificates with no expiration 335 date and to let a device management solution manage the lifetime of 336 all the certificates used by the device. While this approach does 337 not utilize certificates to its widest extent, it is a solution that 338 extends the capabilities offered by a raw public key approach. 340 15.1.6. subjectPublicKeyInfo 342 The SubjectPublicKeyInfo structure indicates the algorithm and any 343 associated parameters for the ECC public key. This profile uses the 344 id-ecPublicKey algorithm identifier for ECDSA signature keys, as 345 defined and specified in [RFC5480]. 347 15.2. Root CA Certificate 349 * basicConstraints MUST be present and MUST be marked critical. The 350 cA field MUST be set true. The pathLenConstraint field SHOULD NOT 351 be present. 352 * keyUsage MUST be present and MUST be marked critical. Bit 353 position for keyCertSign MUST be set. 354 * extendedKeyUsage MUST NOT be present. 356 15.3. Intermediate CA Certificate 358 * basicConstraints MUST be present and MUST be marked critical. The 359 cA field MUST be set true. The pathLenConstraint field MAY be 360 present. 361 * keyUsage MUST be present and MUST be marked critical. Bit 362 position for keyCertSign MUST be set. 363 * extendedKeyUsage MUST NOT be present. 365 15.4. End Entity Certificate 367 * extendedKeyUsage MUST be present and contain at least one of id- 368 kp-serverAuth or id-kp-clientAuth. 369 * keyUsage MAY be present and contain one of digitalSignature or 370 keyAgreement. 371 * Domain names MUST NOT be encoded in the subject commonName, 372 instead they MUST be encoded in a subjectAltName of type DNS-ID. 373 Domain names MUST NOT contain wildcard (*) characters. 374 subjectAltName MUST NOT contain multiple names. 376 15.4.1. Client Certificate Subject 378 The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for 379 client certificates is lifted. 381 If the EUI-64 format is used to identify the subject of a client 382 certificate, it MUST be encoded in a subjectAltName of type DNS-ID as 383 a string of the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the 384 symbols '0'-'9' or 'A'-'F'. 386 16. Certificate Revocation Checks 388 The considerations in Section 4.4.3 of [RFC7925] hold. 390 Since the publication of RFC 7925 the need for firmware update 391 mechanisms has been reinforced and the work on standardizing a secure 392 and interoperable firmware update mechanism has made substantial 393 progress, see [I-D.ietf-suit-architecture]. RFC 7925 recommends to 394 use a software / firmware update mechanism to provision devices with 395 new trust anchors. 397 The use of device management protocols for IoT devices, which often 398 include an onboarding or bootstrapping mechanism, has also seen 399 considerable uptake in deployed devices and these protocols, some of 400 which are standardized, allow provision of certificates on a regular 401 basis. This enables a deployment model where IoT device utilize end- 402 entity certificates with shorter lifetime making certificate 403 revocation protocols, like OCSP and CRLs, less relevant. 405 Hence, instead of performing certificate revocation checks on the IoT 406 device itself this specification recommends to delegate this task to 407 the IoT device operator and to take the necessary action to allow IoT 408 devices to remain operational. 410 17. Certificate Overhead 412 In a public key-based key exchange, certificates and public keys are 413 a major contributor to the size of the overall handshake. For 414 example, in a regular TLS 1.3 handshake with minimal ECC certificates 415 and no intermediate CA utilizing the secp256r1 curve with mutual 416 authentication, around 40% of the entire handshake payload is 417 consumed by the two exchanged certificates. 419 Hence, it is not surprising that there is a strong desire to reduce 420 the size of certificates and certificate chains. This has lead to 421 various standardization efforts. Here is a brief summary of what 422 options an implementer has to reduce the bandwidth requirements of a 423 public key-based key exchange: 425 * Use elliptic curve cryptography (ECC) instead of RSA-based 426 certificate due to the smaller certificate size. 427 * Avoid deep and complex CA hierarchies to reduce the number of 428 intermediate CA certificates that need to be transmitted. 429 * Pay attention to the amount of information conveyed inside 430 certificates. 431 * Use session resumption to reduce the number of times a full 432 handshake is needed. Use Connection IDs [DTLS-CID], when 433 possible, to enable long-lasting connections. 434 * Use the TLS cached info [RFC7924] extension to avoid sending 435 certificates with every full handshake. 436 * Use client certificate URLs [RFC6066] instead of full certificates 437 for clients. 438 * Use certificate compression as defined in 439 [I-D.ietf-tls-certificate-compression]. 440 * Use alternative certificate formats, where possible, such as raw 441 public keys [RFC7250] or CBOR-encoded certificates 442 [I-D.ietf-cose-cbor-encoded-cert]. 444 The use of certificate handles, as introduced in cTLS 445 [I-D.ietf-tls-ctls], is a form of caching or compressing certificates 446 as well. 448 Whether to utilize any of the above extensions or a combination of 449 them depends on the anticipated deployment environment, the 450 availability of code, and the constraints imposed by already deployed 451 infrastructure (e.g., CA infrastructure, tool support). 453 18. Ciphersuites 455 Section 4.5.3 of [DTLS13] flags AES-CCM with 8-octet authentication 456 tags (CCM_8) as unsuitable for general use with DTLS. In fact, due 457 to its low integrity limits (i.e., a high sensitivity to forgeries), 458 endpoints that negotiate ciphersuites based on such AEAD are 459 susceptible to a trivial DoS. (See also Section 5.3 and 5.4 of 460 [I-D.irtf-cfrg-aead-limits] for further discussion on this topic, as 461 well as references to the analysis supporting these conclusions.) 463 Specifically, [DTLS13] warns that: 465 "TLS_AES_128_CCM_8_SHA256 MUST NOT be used in DTLS without 466 additional safeguards against forgery. Implementations MUST set 467 usage limits for AEAD_AES_128_CCM_8 based on an understanding of 468 any additional forgery protections that are used." 470 Since all the ciphersuites mandated by [RFC7925] and [CoAP] are based 471 on CCM_8, there is no stand-by ciphersuite to use for applications 472 that want to avoid the security and availability risks associated 473 with CCM_8 while retaining interoperability with the rest of the 474 ecosystem. 476 In order to ameliorate the situation, this document RECOMMENDS that 477 implementations support the following two ciphersuites: 479 * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 480 * TLS_ECDHE_ECDSA_WITH_AES_128_CCM 482 and offer them as their first choice. These ciphersuites provide 483 confidentiality and integrity limits that are considered acceptable 484 in the most general settings. For the details on the exact bounds of 485 both ciphersuites see Section 4.5.3 of [DTLS13]. Note that the GCM- 486 based ciphersuite offers superior interoperability with cloud 487 services at the cost of a slight increase in the wire and peak RAM 488 footprints. 490 When the GCM-based ciphersuite is used with TLS 1.2, the 491 recommendations in Section 6.2.1 of [RFC7525bis] related to 492 deterministic nonce generation apply. In addition, the integrity 493 limits on key usage detailed in Section 4.4 of [RFC7525bis] also 494 apply. 496 19. Open Issues 498 A list of open issues can be found at https://github.com/thomas- 499 fossati/draft-tls13-iot/issues 501 20. Security Considerations 503 This entire document is about security. 505 21. Acknowledgements 507 We would like to thank Ben Kaduk and John Mattsson. 509 22. IANA Considerations 511 IANA is asked to add the Option defined in Figure 2 to the CoAP 512 Option Numbers registry. 514 +--------+------------+-----------+ 515 | Number | Name | Reference | 516 +--------+------------+-----------+ 517 | TBD | Early-Data | RFCThis | 518 +--------+------------+-----------+ 520 Figure 2: Early-Data Option 522 IANA is asked to add the Response Code defined in Figure 3 to the 523 CoAP Response Code registry. 525 +--------+-------------+-----------+ 526 | Code | Description | Reference | 527 +--------+-------------+-----------+ 528 | 4.25 | Too Early | RFCThis | 529 +--------+-------------+-----------+ 531 Figure 3: Too Early Response Code 533 23. References 535 23.1. Normative References 537 [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 538 Datagram Transport Layer Security (DTLS) Protocol Version 539 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 540 dtls13-43, 30 April 2021, 541 . 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, 546 DOI 10.17487/RFC2119, March 1997, 547 . 549 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 550 Housley, R., and W. Polk, "Internet X.509 Public Key 551 Infrastructure Certificate and Certificate Revocation List 552 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 553 . 555 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 556 "Elliptic Curve Cryptography Subject Public Key 557 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 558 . 560 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 561 Polk, "Internet X.509 Public Key Infrastructure: 562 Additional Algorithms and Identifiers for DSA and ECDSA", 563 RFC 5758, DOI 10.17487/RFC5758, January 2010, 564 . 566 [RFC7525bis] 567 Sheffer, Y., Saint-Andre, P., and T. Fossati, 568 "Recommendations for Secure Use of Transport Layer 569 Security (TLS) and Datagram Transport Layer Security 570 (DTLS)", Work in Progress, Internet-Draft, draft-ietf-uta- 571 rfc7525bis-05, 3 February 2022, 572 . 575 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 576 Security (TLS) / Datagram Transport Layer Security (DTLS) 577 Profiles for the Internet of Things", RFC 7925, 578 DOI 10.17487/RFC7925, July 2016, 579 . 581 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 582 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 583 May 2017, . 585 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 586 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 587 . 589 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 590 RFC 8449, DOI 10.17487/RFC8449, August 2018, 591 . 593 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 594 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 595 2018, . 597 23.2. Informative References 599 [CoAP] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 600 Application Protocol (CoAP)", RFC 7252, 601 DOI 10.17487/RFC7252, June 2014, 602 . 604 [DTLS-CID] Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 605 "Connection Identifiers for DTLS 1.2", Work in Progress, 606 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 607 June 2021, . 610 [I-D.ietf-cose-cbor-encoded-cert] 611 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 612 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 613 Certificates)", Work in Progress, Internet-Draft, draft- 614 ietf-cose-cbor-encoded-cert-03, 10 January 2022, 615 . 618 [I-D.ietf-suit-architecture] 619 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 620 Firmware Update Architecture for Internet of Things", Work 621 in Progress, Internet-Draft, draft-ietf-suit-architecture- 622 16, 27 January 2021, 623 . 626 [I-D.ietf-tls-certificate-compression] 627 Ghedini, A. and V. Vasiliev, "TLS Certificate 628 Compression", Work in Progress, Internet-Draft, draft- 629 ietf-tls-certificate-compression-10, 6 January 2020, 630 . 633 [I-D.ietf-tls-ctls] 634 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 635 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 636 ctls-04, 25 October 2021, 637 . 640 [I-D.ietf-tls-esni] 641 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 642 Encrypted Client Hello", Work in Progress, Internet-Draft, 643 draft-ietf-tls-esni-14, 13 February 2022, 644 . 647 [I-D.irtf-cfrg-aead-limits] 648 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on 649 AEAD Algorithms", Work in Progress, Internet-Draft, draft- 650 irtf-cfrg-aead-limits-03, 12 July 2021, 651 . 654 [I-D.irtf-cfrg-hpke] 655 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 656 "Hybrid Public Key Encryption", Work in Progress, 657 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 658 . 661 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 662 Extensions: Extension Definitions", RFC 6066, 663 DOI 10.17487/RFC6066, January 2011, 664 . 666 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 667 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 668 Transport Layer Security (TLS) and Datagram Transport 669 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 670 June 2014, . 672 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 673 and P. Hoffman, "Specification for DNS over Transport 674 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 675 2016, . 677 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 678 (TLS) Cached Information Extension", RFC 7924, 679 DOI 10.17487/RFC7924, July 2016, 680 . 682 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 683 Transport Layer Security (DTLS)", RFC 8094, 684 DOI 10.17487/RFC8094, February 2017, 685 . 687 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 688 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 689 . 691 Authors' Addresses 693 Hannes Tschofenig 694 Arm Limited 695 Email: Hannes.Tschofenig@gmx.net 697 Thomas Fossati 698 Arm Limited 699 Email: Thomas.Fossati@arm.com