idnits 2.17.1 draft-ietf-uta-tls13-iot-profile-02.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: ---------------------------------------------------------------------------- == There is 1 instance 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 July 2021) is 1019 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 (-09) exists of draft-ietf-cose-cbor-encoded-cert-01 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-02 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-12 == Outdated reference: A later version (-11) exists of draft-ietf-uta-rfc7525bis-01 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-10 Summary: 0 errors (**), 0 flaws (~~), 7 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 12 July 2021 6 Expires: 13 January 2022 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-ietf-uta-tls13-iot-profile-02 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 13 January 2022. 41 Copyright Notice 43 Copyright (c) 2021 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 Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified 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 17.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . 10 87 18. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 21.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 21.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 Indication (SNI), 145 * Pre-Shared Key, 146 * PSK Key Exchange Modes, and 147 * Application-Layer Protocol Negotiation (ALPN). 149 The SNI extension is discussed in this document and the justification 150 for implementing and using the ALPN extension can be found in 151 [I-D.ietf-uta-rfc7525bis]. 153 For TLS/DTLS clients and servers implementing raw public keys and/or 154 certificates the guidance for mandatory-to-implement extensions 155 described in Section 9.2 of [RFC8446] MUST be followed. 157 3. Error Handling 159 TLS 1.3 simplified the Alert protocol but the underlying challenge in 160 an embedded context remains unchanged, namely what should an IoT 161 device do when it encounters an error situation. The classical 162 approach used in a desktop environment where the user is prompted is 163 often not applicable with unattended devices. Hence, it is more 164 important for a developer to find out from which error cases a device 165 can recover from. 167 4. Session Resumption 169 TLS 1.3 has built-in support for session resumption by utilizing PSK- 170 based credentials established in an earlier exchange. 172 5. Compression 174 TLS 1.3 does not have support for compression of application data 175 traffic, as offered by previous versions of TLS. Applications are 176 therefore responsible for transmitting payloads that are either 177 compressed or use a more efficient encoding otherwise. 179 With regards to the handshake itself, various strategies have been 180 applied to reduce the size of the exchanged payloads. TLS and DTLS 181 1.3 use less overhead, depending on the type of key confirmations, 182 when compared to previous versions of the protocol. Additionally, 183 the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken 184 compression of the handshake a step further by utilizing out-of-band 185 knowledge between the communication parties to reduce the amount of 186 data to be transmitted at each individual handshake, among applying 187 other techniques. 189 6. Perfect Forward Secrecy 191 TLS 1.3 allows the use of PFS with all ciphersuites since the support 192 for it is negotiated independently. 194 7. Keep-Alive 196 The discussion in Section 10 of [RFC7925] is applicable. 198 8. Timeouts 200 The recommendation in Section 11 of [RFC7925] is applicable. In 201 particular this document RECOMMENDED to use an initial timer value of 202 9 seconds with exponential back off up to no less then 60 seconds. 204 9. Random Number Generation 206 The discussion in Section 12 of [RFC7925] is applicable with one 207 exception: the ClientHello and the ServerHello messages in TLS 1.3 do 208 not contain gmt_unix_time component anymore. 210 10. Server Name Indication 212 This specification mandates the implementation of the Server Name 213 Indication (SNI) extension. Where privacy requirements require it, 214 the Encrypted Client Hello extension [I-D.ietf-tls-esni] prevents an 215 on-path attacker to determine the domain name the client is trying to 216 connect to. 218 Note: To avoid leaking DNS lookups from network inspection altogether 219 further protocols are needed, including DoH [RFC8484] and DPRIVE 220 [RFC7858] [RFC8094]. Since the Encrypted Client Hello extension 221 requires use of Hybrid Public Key Encryption (HPKE) 222 [I-D.irtf-cfrg-hpke] and additional protocols require further 223 protocol exchanges and cryptographic operations, there is a certain 224 amount of overhead associated with this privacy property. 226 11. Maximum Fragment Length Negotiation 228 The Maximum Fragment Length Negotiation (MFL) extension has been 229 superseded by the Record Size Limit (RSL) extension [RFC8449]. 230 Implementations in compliance with this specification MUST implement 231 the RSL extension and SHOULD use it to indicate their RAM 232 limitations. 234 12. Crypto Agility 236 The recommendations in Section 19 of [RFC7925] are applicable. 238 13. Key Length Recommendations 240 The recommendations in Section 20 of [RFC7925] are applicable. 242 14. 0-RTT Data 244 When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to 245 send data on the first flight ("early data"). This features reduces 246 communication setup latency but requires application layer protocols 247 to define its use with the 0-RTT data functionality. 249 For HTTP this functionality is described in [RFC8470]. This document 250 specifies the application profile for CoAP, which follows the design 251 of [RFC8470]. 253 For a given request, the level of tolerance to replay risk is 254 specific to the resource it operates upon (and therefore only known 255 to the origin server). In general, if processing a request does not 256 have state-changing side effects, the consequences of replay are not 257 significant. The server can choose whether it will process early 258 data before the TLS handshake completes. 260 It is RECOMMENDED that origin servers allow resources to explicitly 261 configure whether early data is appropriate in requests. 263 This specification specifies the Early-Data option, which indicates 264 that the request has been conveyed in early data and that a client 265 understands the 4.25 (Too Early) status code. The semantic follows 266 [RFC8470]. 268 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 269 | No. | C | U | N | R | Name | Format | Length | Default | E | 270 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 271 | TBD | x | | | | Early-Data | empty | 0 | (none) | x | 272 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 274 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 275 E=Encrypt and Integrity Protect (when using OSCORE) 277 Figure 1: Early-Data Option 279 15. Certificate Profile 281 This section contains updates and clarifications to the certificate 282 profile defined in [RFC7925]. The content of Table 1 of [RFC7925] 283 has been split by certificate "type" in order to clarify exactly what 284 requirements and recommendations apply to which entity in the PKI 285 hierarchy. 287 15.1. All Certificates 289 15.1.1. Version 291 Certificates MUST be of type X.509 v3. 293 15.1.2. Serial Number 295 CAs SHALL generate non-sequential Certificate serial numbers greater 296 than zero (0) containing at least 64 bits of output from a CSPRNG 297 (cryptographically secure pseudo-random number generator). 299 15.1.3. Signature 301 The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. 303 15.1.4. Issuer 305 Contains the DN of the issuing CA. 307 15.1.5. Validity 309 No maximum validity period is mandated. Validity values are 310 expressed in notBefore and notAfter fields, as described in 311 Section 4.1.2.5 of [RFC5280]. In particular, values MUST be 312 expressed in Greenwich Mean Time (Zulu) and MUST include seconds even 313 where the number of seconds is zero. 315 Note that the validity period is defined as the period of time from 316 notBefore through notAfter, inclusive. This means that a 317 hypothetical certificate with a notBefore date of 9 June 2021 at 318 03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes 319 valid at the beginning of the :01 second, and only becomes invalid at 320 the :02 second, a period that is 90 days plus 1 second. So for a 321 90-day, notAfter must actually be 03:42:00. 323 In many cases it is necessary to indicate that a certificate does not 324 expire. This is likely to be the case for manufacturer-provisioned 325 certificates. RFC 5280 provides a simple solution to convey the fact 326 that a certificate has no well-defined expiration date by setting the 327 notAfter to the GeneralizedTime value of 99991231235959Z. 329 Some devices might not have a reliable source of time and for those 330 devices it is also advisable to use certificates with no expiration 331 date and to let a device management solution manage the lifetime of 332 all the certificates used by the device. While this approach does 333 not utilize certificates to its widest extent, it is a solution that 334 extends the capabilities offered by a raw public key approach. 336 15.1.6. subjectPublicKeyInfo 338 The SubjectPublicKeyInfo structure indicates the algorithm and any 339 associated parameters for the ECC public key. This profile uses the 340 id-ecPublicKey algorithm identifier for ECDSA signature keys, as 341 defined and specified in [RFC5480]. 343 15.2. Root CA Certificate 345 * basicConstraints MUST be present and MUST be marked critical. The 346 cA field MUST be set true. The pathLenConstraint field SHOULD NOT 347 be present. 348 * keyUsage MUST be present and MUST be marked critical. Bit 349 position for keyCertSign MUST be set. 350 * extendedKeyUsage MUST NOT be present. 352 15.3. Intermediate CA Certificate 354 * basicConstraints MUST be present and MUST be marked critical. The 355 cA field MUST be set true. The pathLenConstraint field MAY be 356 present. 357 * keyUsage MUST be present and MUST be marked critical. Bit 358 position for keyCertSign MUST be set. 359 * extendedKeyUsage MUST NOT be present. 361 15.4. End Entity Certificate 363 * extendedKeyUsage MUST be present and contain at least one of id- 364 kp-serverAuth or id-kp-clientAuth. 365 * keyUsage MAY be present and contain one of digitalSignature or 366 keyAgreement. 367 * Domain names MUST NOT be encoded in the subject commonName, 368 instead they MUST be encoded in a subjectAltName of type DNS-ID. 369 Domain names MUST NOT contain wildcard ("*") characters. 370 subjectAltName MUST NOT contain multiple names. 372 15.4.1. Client Certificate Subject 374 The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for 375 client certificates is lifted. 377 If the EUI-64 format is used to identify the subject of a client 378 certificate, it MUST be encoded in a subjectAltName of type DNS-ID as 379 a string of the form "HH-HH-HH-HH-HH-HH-HH-HH" where 'H' is one of 380 the symbols '0'-'9' or 'A'-'F'. 382 16. Certificate Revocation Checks 384 The considerations in Section 4.4.3 of [RFC7925] hold. 386 Since the publication of RFC 7925 the need for firmware update 387 mechanisms has been reinforced and the work on standardizing a secure 388 and interoperable firmware update mechanism has made substantial 389 progress, see [I-D.ietf-suit-architecture]. RFC 7925 recommends to 390 use a software / firmware update mechanism to provision devices with 391 new trust anchors. 393 The use of device management protocols for IoT devices, which often 394 include an onboarding or bootstrapping mechanism, has also seen 395 considerable uptake in deployed devices and these protocols, some of 396 which are standardized, allow provision of certificates on a regular 397 basis. This enables a deployment model where IoT device utilize end- 398 entity certificates with shorter lifetime making certificate 399 revocation protocols, like OCSP and CRLs, less relevant. 401 Hence, instead of performing certificate revocation checks on the IoT 402 device itself this specification recommends to delegate this task to 403 the IoT device operator and to take the necessary action to allow IoT 404 devices to remain operational. 406 17. Certificate Overhead 408 In a public key-based key exchange, certificates and public keys are 409 a major contributor to the size of the overall handshake. For 410 example, in a regular TLS 1.3 handshake with minimal ECC certificates 411 and no intermediate CA utilizing the secp256r1 curve with mutual 412 authentication, around 40% of the entire handshake payload is 413 consumed by the two exchanged certificates. 415 Hence, it is not surprising that there is a strong desire to reduce 416 the size of certificates and certificate chains. This has lead to 417 various standardization efforts. Here is a brief summary of what 418 options an implementer has to reduce the bandwidth requirements of a 419 public key-based key exchange: 421 * Use elliptic curve cryptography (ECC) instead of RSA-based 422 certificate due to the smaller certificate size. 423 * Avoid deep and complex CA hierarchies to reduce the number of 424 intermediate CA certificates that need to be transmitted. 425 * Pay attention to the amount of information conveyed inside 426 certificates. 427 * Use session resumption to reduce the number of times a full 428 handshake is needed. Use Connection IDs 429 [I-D.ietf-tls-dtls-connection-id], when possible, to enable long- 430 lasting connections. 431 * Use the TLS cached info [RFC7924] extension to avoid sending 432 certificates with every full handshake. 433 * Use client certificate URLs [RFC6066] instead of full certificates 434 for clients. 435 * Use certificate compression as defined in 436 [I-D.ietf-tls-certificate-compression]. 437 * Use alternative certificate formats, where possible, such as raw 438 public keys [RFC7250] or CBOR-encoded certificates 439 [I-D.ietf-cose-cbor-encoded-cert]. 441 The use of certificate handles, as introduced in cTLS 442 [I-D.ietf-tls-ctls], is a form of caching or compressing certificates 443 as well. 445 Whether to utilize any of the above extensions or a combination of 446 them depends on the anticipated deployment environment, the 447 availability of code, and the constraints imposed by already deployed 448 infrastructure (e.g., CA infrastructure, tool support). 450 17.1. Open Issues 452 A list of open issues can be found at https://github.com/thomas- 453 fossati/draft-tls13-iot/issues 455 18. Security Considerations 457 This entire document is about security. 459 19. Acknowledgements 461 We would like to thank Ben Kaduk and John Mattsson. 463 20. IANA Considerations 465 IANA is asked to add the Option defined in Figure 2 to the CoAP 466 Option Numbers registry. 468 +--------+------------+-----------+ 469 | Number | Name | Reference | 470 +--------+------------+-----------+ 471 | TBD | Early-Data | RFCThis | 472 +--------+------------+-----------+ 474 Figure 2: Early-Data Option 476 IANA is asked to add the Response Code defined in Figure 3 to the 477 CoAP Response Code registry. 479 +--------+-------------+-----------+ 480 | Code | Description | Reference | 481 +--------+-------------+-----------+ 482 | 4.25 | Too Early | RFCThis | 483 +--------+-------------+-----------+ 485 Figure 3: Too Early Response Code 487 21. References 489 21.1. Normative References 491 [I-D.ietf-tls-dtls13] 492 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 493 Datagram Transport Layer Security (DTLS) Protocol Version 494 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 495 dtls13-43, 30 April 2021, 496 . 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", BCP 14, RFC 2119, 501 DOI 10.17487/RFC2119, March 1997, 502 . 504 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 505 Housley, R., and W. Polk, "Internet X.509 Public Key 506 Infrastructure Certificate and Certificate Revocation List 507 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 508 . 510 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 511 "Elliptic Curve Cryptography Subject Public Key 512 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 513 . 515 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 516 Polk, "Internet X.509 Public Key Infrastructure: 517 Additional Algorithms and Identifiers for DSA and ECDSA", 518 RFC 5758, DOI 10.17487/RFC5758, January 2010, 519 . 521 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 522 Security (TLS) / Datagram Transport Layer Security (DTLS) 523 Profiles for the Internet of Things", RFC 7925, 524 DOI 10.17487/RFC7925, July 2016, 525 . 527 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 528 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 529 May 2017, . 531 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 532 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 533 . 535 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 536 RFC 8449, DOI 10.17487/RFC8449, August 2018, 537 . 539 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 540 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 541 2018, . 543 21.2. Informative References 545 [I-D.ietf-cose-cbor-encoded-cert] 546 Raza, S., Höglund, J., Selander, G., Mattsson, J. P., and 547 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 548 Certificates)", Work in Progress, Internet-Draft, draft- 549 ietf-cose-cbor-encoded-cert-01, 25 May 2021, 550 . 553 [I-D.ietf-suit-architecture] 554 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 555 Firmware Update Architecture for Internet of Things", Work 556 in Progress, Internet-Draft, draft-ietf-suit-architecture- 557 16, 27 January 2021, 558 . 561 [I-D.ietf-tls-certificate-compression] 562 Ghedini, A. and V. Vasiliev, "TLS Certificate 563 Compression", Work in Progress, Internet-Draft, draft- 564 ietf-tls-certificate-compression-10, 6 January 2020, 565 . 568 [I-D.ietf-tls-ctls] 569 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 570 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 571 ctls-02, 5 May 2021, 572 . 575 [I-D.ietf-tls-dtls-connection-id] 576 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 577 "Connection Identifiers for DTLS 1.2", Work in Progress, 578 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 579 June 2021, . 582 [I-D.ietf-tls-esni] 583 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 584 Encrypted Client Hello", Work in Progress, Internet-Draft, 585 draft-ietf-tls-esni-12, 7 July 2021, 586 . 589 [I-D.ietf-uta-rfc7525bis] 590 Sheffer, Y., Holz, R., Saint-Andre, P., and T. Fossati, 591 "Recommendations for Secure Use of Transport Layer 592 Security (TLS) and Datagram Transport Layer Security 593 (DTLS)", Work in Progress, Internet-Draft, draft-ietf-uta- 594 rfc7525bis-01, 7 July 2021, 595 . 598 [I-D.irtf-cfrg-hpke] 599 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 600 "Hybrid Public Key Encryption", Work in Progress, 601 Internet-Draft, draft-irtf-cfrg-hpke-10, 7 July 2021, 602 . 605 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 606 Extensions: Extension Definitions", RFC 6066, 607 DOI 10.17487/RFC6066, January 2011, 608 . 610 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 611 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 612 Transport Layer Security (TLS) and Datagram Transport 613 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 614 June 2014, . 616 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 617 and P. Hoffman, "Specification for DNS over Transport 618 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 619 2016, . 621 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 622 (TLS) Cached Information Extension", RFC 7924, 623 DOI 10.17487/RFC7924, July 2016, 624 . 626 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 627 Transport Layer Security (DTLS)", RFC 8094, 628 DOI 10.17487/RFC8094, February 2017, 629 . 631 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 632 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 633 . 635 Authors' Addresses 637 Hannes Tschofenig 638 Arm Limited 640 Email: Hannes.Tschofenig@gmx.net 642 Thomas Fossati 643 Arm Limited 645 Email: Thomas.Fossati@arm.com