idnits 2.17.1 draft-ietf-uta-tls13-iot-profile-03.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 (25 October 2021) is 913 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-02 == Outdated reference: A later version (-10) exists of draft-ietf-tls-ctls-04 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-13 == Outdated reference: A later version (-11) exists of draft-ietf-uta-rfc7525bis-03 Summary: 0 errors (**), 0 flaws (~~), 6 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 25 October 2021 6 Expires: 28 April 2022 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-ietf-uta-tls13-iot-profile-03 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 28 April 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 18. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10 87 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 20. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 90 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 23.1. Normative References . . . . . . . . . . . . . . . . . . 11 93 23.2. Informative References . . . . . . . . . . . . . . . . . 12 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and 99 TLS 1.3 [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 [I-D.ietf-uta-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 specification specifies the Early-Data option, which indicates 265 that 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 15. Certificate Profile 282 This section contains updates and clarifications to the certificate 283 profile defined in [RFC7925]. The content of Table 1 of [RFC7925] 284 has been split by certificate "type" in order to clarify exactly what 285 requirements and recommendations apply to which entity in the PKI 286 hierarchy. 288 15.1. All Certificates 290 15.1.1. Version 292 Certificates MUST be of type X.509 v3. 294 15.1.2. Serial Number 296 CAs SHALL generate non-sequential Certificate serial numbers greater 297 than zero (0) containing at least 64 bits of output from a CSPRNG 298 (cryptographically secure pseudo-random number generator). 300 15.1.3. Signature 302 The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758]. 304 15.1.4. Issuer 306 Contains the DN of the issuing CA. 308 15.1.5. Validity 310 No maximum validity period is mandated. Validity values are 311 expressed in notBefore and notAfter fields, as described in 312 Section 4.1.2.5 of [RFC5280]. In particular, values MUST be 313 expressed in Greenwich Mean Time (Zulu) and MUST include seconds even 314 where the number of seconds is zero. 316 Note that the validity period is defined as the period of time from 317 notBefore through notAfter, inclusive. This means that a 318 hypothetical certificate with a notBefore date of 9 June 2021 at 319 03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes 320 valid at the beginning of the :01 second, and only becomes invalid at 321 the :02 second, a period that is 90 days plus 1 second. So for a 322 90-day, notAfter must actually be 03:42:00. 324 In many cases it is necessary to indicate that a certificate does not 325 expire. This is likely to be the case for manufacturer-provisioned 326 certificates. RFC 5280 provides a simple solution to convey the fact 327 that a certificate has no well-defined expiration date by setting the 328 notAfter to the GeneralizedTime value of 99991231235959Z. 330 Some devices might not have a reliable source of time and for those 331 devices it is also advisable to use certificates with no expiration 332 date and to let a device management solution manage the lifetime of 333 all the certificates used by the device. While this approach does 334 not utilize certificates to its widest extent, it is a solution that 335 extends the capabilities offered by a raw public key approach. 337 15.1.6. subjectPublicKeyInfo 339 The SubjectPublicKeyInfo structure indicates the algorithm and any 340 associated parameters for the ECC public key. This profile uses the 341 id-ecPublicKey algorithm identifier for ECDSA signature keys, as 342 defined and specified in [RFC5480]. 344 15.2. Root CA Certificate 346 * basicConstraints MUST be present and MUST be marked critical. The 347 cA field MUST be set true. The pathLenConstraint field SHOULD NOT 348 be present. 349 * keyUsage MUST be present and MUST be marked critical. Bit 350 position for keyCertSign MUST be set. 351 * extendedKeyUsage MUST NOT be present. 353 15.3. Intermediate CA Certificate 355 * basicConstraints MUST be present and MUST be marked critical. The 356 cA field MUST be set true. The pathLenConstraint field MAY be 357 present. 358 * keyUsage MUST be present and MUST be marked critical. Bit 359 position for keyCertSign MUST be set. 360 * extendedKeyUsage MUST NOT be present. 362 15.4. End Entity Certificate 364 * extendedKeyUsage MUST be present and contain at least one of id- 365 kp-serverAuth or id-kp-clientAuth. 366 * keyUsage MAY be present and contain one of digitalSignature or 367 keyAgreement. 368 * Domain names MUST NOT be encoded in the subject commonName, 369 instead they MUST be encoded in a subjectAltName of type DNS-ID. 370 Domain names MUST NOT contain wildcard (*) characters. 371 subjectAltName MUST NOT contain multiple names. 373 15.4.1. Client Certificate Subject 375 The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for 376 client certificates is lifted. 378 If the EUI-64 format is used to identify the subject of a client 379 certificate, it MUST be encoded in a subjectAltName of type DNS-ID as 380 a string of the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the 381 symbols '0'-'9' or 'A'-'F'. 383 16. Certificate Revocation Checks 385 The considerations in Section 4.4.3 of [RFC7925] hold. 387 Since the publication of RFC 7925 the need for firmware update 388 mechanisms has been reinforced and the work on standardizing a secure 389 and interoperable firmware update mechanism has made substantial 390 progress, see [I-D.ietf-suit-architecture]. RFC 7925 recommends to 391 use a software / firmware update mechanism to provision devices with 392 new trust anchors. 394 The use of device management protocols for IoT devices, which often 395 include an onboarding or bootstrapping mechanism, has also seen 396 considerable uptake in deployed devices and these protocols, some of 397 which are standardized, allow provision of certificates on a regular 398 basis. This enables a deployment model where IoT device utilize end- 399 entity certificates with shorter lifetime making certificate 400 revocation protocols, like OCSP and CRLs, less relevant. 402 Hence, instead of performing certificate revocation checks on the IoT 403 device itself this specification recommends to delegate this task to 404 the IoT device operator and to take the necessary action to allow IoT 405 devices to remain operational. 407 17. Certificate Overhead 409 In a public key-based key exchange, certificates and public keys are 410 a major contributor to the size of the overall handshake. For 411 example, in a regular TLS 1.3 handshake with minimal ECC certificates 412 and no intermediate CA utilizing the secp256r1 curve with mutual 413 authentication, around 40% of the entire handshake payload is 414 consumed by the two exchanged certificates. 416 Hence, it is not surprising that there is a strong desire to reduce 417 the size of certificates and certificate chains. This has lead to 418 various standardization efforts. Here is a brief summary of what 419 options an implementer has to reduce the bandwidth requirements of a 420 public key-based key exchange: 422 * Use elliptic curve cryptography (ECC) instead of RSA-based 423 certificate due to the smaller certificate size. 424 * Avoid deep and complex CA hierarchies to reduce the number of 425 intermediate CA certificates that need to be transmitted. 426 * Pay attention to the amount of information conveyed inside 427 certificates. 428 * Use session resumption to reduce the number of times a full 429 handshake is needed. Use Connection IDs 430 [I-D.ietf-tls-dtls-connection-id], when possible, to enable long- 431 lasting connections. 432 * Use the TLS cached info [RFC7924] extension to avoid sending 433 certificates with every full handshake. 434 * Use client certificate URLs [RFC6066] instead of full certificates 435 for clients. 436 * Use certificate compression as defined in 437 [I-D.ietf-tls-certificate-compression]. 438 * Use alternative certificate formats, where possible, such as raw 439 public keys [RFC7250] or CBOR-encoded certificates 440 [I-D.ietf-cose-cbor-encoded-cert]. 442 The use of certificate handles, as introduced in cTLS 443 [I-D.ietf-tls-ctls], is a form of caching or compressing certificates 444 as well. 446 Whether to utilize any of the above extensions or a combination of 447 them depends on the anticipated deployment environment, the 448 availability of code, and the constraints imposed by already deployed 449 infrastructure (e.g., CA infrastructure, tool support). 451 18. Ciphersuites 453 // As soon as the ongoing discussion around CCM_8 deprecation 454 // settles, provide summary and capture the consensus. 456 19. Open Issues 458 A list of open issues can be found at https://github.com/thomas- 459 fossati/draft-tls13-iot/issues 461 20. Security Considerations 463 This entire document is about security. 465 21. Acknowledgements 467 We would like to thank Ben Kaduk and John Mattsson. 469 22. IANA Considerations 471 IANA is asked to add the Option defined in Figure 2 to the CoAP 472 Option Numbers registry. 474 +--------+------------+-----------+ 475 | Number | Name | Reference | 476 +--------+------------+-----------+ 477 | TBD | Early-Data | RFCThis | 478 +--------+------------+-----------+ 480 Figure 2: Early-Data Option 482 IANA is asked to add the Response Code defined in Figure 3 to the 483 CoAP Response Code registry. 485 +--------+-------------+-----------+ 486 | Code | Description | Reference | 487 +--------+-------------+-----------+ 488 | 4.25 | Too Early | RFCThis | 489 +--------+-------------+-----------+ 491 Figure 3: Too Early Response Code 493 23. References 495 23.1. Normative References 497 [I-D.ietf-tls-dtls13] 498 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 499 Datagram Transport Layer Security (DTLS) Protocol Version 500 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 501 dtls13-43, 30 April 2021, 502 . 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, 507 DOI 10.17487/RFC2119, March 1997, 508 . 510 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 511 Housley, R., and W. Polk, "Internet X.509 Public Key 512 Infrastructure Certificate and Certificate Revocation List 513 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 514 . 516 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 517 "Elliptic Curve Cryptography Subject Public Key 518 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 519 . 521 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 522 Polk, "Internet X.509 Public Key Infrastructure: 523 Additional Algorithms and Identifiers for DSA and ECDSA", 524 RFC 5758, DOI 10.17487/RFC5758, January 2010, 525 . 527 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 528 Security (TLS) / Datagram Transport Layer Security (DTLS) 529 Profiles for the Internet of Things", RFC 7925, 530 DOI 10.17487/RFC7925, July 2016, 531 . 533 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 534 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 535 May 2017, . 537 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 538 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 539 . 541 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 542 RFC 8449, DOI 10.17487/RFC8449, August 2018, 543 . 545 [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 546 Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 547 2018, . 549 23.2. Informative References 551 [I-D.ietf-cose-cbor-encoded-cert] 552 Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and 553 M. Furuhed, "CBOR Encoded X.509 Certificates (C509 554 Certificates)", Work in Progress, Internet-Draft, draft- 555 ietf-cose-cbor-encoded-cert-02, 12 July 2021, 556 . 559 [I-D.ietf-suit-architecture] 560 Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A 561 Firmware Update Architecture for Internet of Things", Work 562 in Progress, Internet-Draft, draft-ietf-suit-architecture- 563 16, 27 January 2021, 564 . 567 [I-D.ietf-tls-certificate-compression] 568 Ghedini, A. and V. Vasiliev, "TLS Certificate 569 Compression", Work in Progress, Internet-Draft, draft- 570 ietf-tls-certificate-compression-10, 6 January 2020, 571 . 574 [I-D.ietf-tls-ctls] 575 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 576 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 577 ctls-04, 25 October 2021, 578 . 581 [I-D.ietf-tls-dtls-connection-id] 582 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, 583 "Connection Identifiers for DTLS 1.2", Work in Progress, 584 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 585 June 2021, . 588 [I-D.ietf-tls-esni] 589 Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 590 Encrypted Client Hello", Work in Progress, Internet-Draft, 591 draft-ietf-tls-esni-13, 12 August 2021, 592 . 595 [I-D.ietf-uta-rfc7525bis] 596 Sheffer, Y., Holz, R., Saint-Andre, P., and T. Fossati, 597 "Recommendations for Secure Use of Transport Layer 598 Security (TLS) and Datagram Transport Layer Security 599 (DTLS)", Work in Progress, Internet-Draft, draft-ietf-uta- 600 rfc7525bis-03, 25 October 2021, 601 . 604 [I-D.irtf-cfrg-hpke] 605 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 606 "Hybrid Public Key Encryption", Work in Progress, 607 Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021, 608 . 611 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 612 Extensions: Extension Definitions", RFC 6066, 613 DOI 10.17487/RFC6066, January 2011, 614 . 616 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 617 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 618 Transport Layer Security (TLS) and Datagram Transport 619 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 620 June 2014, . 622 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 623 and P. Hoffman, "Specification for DNS over Transport 624 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 625 2016, . 627 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 628 (TLS) Cached Information Extension", RFC 7924, 629 DOI 10.17487/RFC7924, July 2016, 630 . 632 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 633 Transport Layer Security (DTLS)", RFC 8094, 634 DOI 10.17487/RFC8094, February 2017, 635 . 637 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 638 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 639 . 641 Authors' Addresses 643 Hannes Tschofenig 644 Arm Limited 646 Email: Hannes.Tschofenig@gmx.net 648 Thomas Fossati 649 Arm Limited 651 Email: Thomas.Fossati@arm.com