]> University of Applied Sciences Bonn-Rhein-Sieg

Germany Hannes.Tschofenig@gmx.net

Linaro

Thomas.Fossati@linaro.org

Sandelman Software Works

mcr+ietf@sandelman.ca

Security UTA Internet-Draft RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction In the rapidly evolving Internet of Things (IoT) ecosystem, communication security is a critical requirement. The Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols have been foundational for ensuring encryption, integrity, and authenticity in communications. However, the constraints of a certain class of IoT devices render conventional, off-the-shelf TLS/DTLS implementations suboptimal for many IoT use cases. This document addresses these limitations by specifying TLS 1.3 and DTLS 1.3 profiles that are optimized for resource-constrained IoT devices. Note that IoT devices vary widely in terms of capabilities. While some are highly resource-constrained, others offer performance comparable to regular desktop computers but operate without end-user interfaces. For a detailed description of the different classes of IoT devices, please refer to and . It is crucial for developers to thoroughly assess the limitations of their IoT devices and communication technologies to implement the most suitable optimizations. The profiles in this document aim to balance strong security with the hardware and software limitations of IoT devices. TLS 1.3 has been re-designed and several previously defined extensions are not applicable to the new version of TLS/DTLS anymore. The following features changed with the transition from TLS 1.2 to 1.3:

• TLS 1.3 introduced the concept of post-handshake authentication messages, which partially replaced the need for the re-negotiation feature available in earlier TLS versions. However, the rekeying mechanism defined in does not provide post-compromise security (see ). Furthermore, post-handshake authentication defined in only offers client-to-server authentication. The "Exported Authenticator" specification, see , added support for mutual post-handshake authentication, but this requires the Certificate, CertificateVerify and the Finished messages to be conveyed by the application layer protocol, as it is exercised for HTTP/2 and HTTP/3 in . Therefore, the application layer protocol must be enhanced whenever this feature is required.
• Rekeying of the application traffic secret does not lead to an update of the exporter secret (see ) since the derived export secret is based on the exporter_master_secret and not on the application traffic secret.
• Flight #4, which was used by EAP-TLS 1.2 , does not exist in TLS 1.3. As a consequence, EAP-TLS 1.3 introduced a dummy message.
• introduced PSK-based authentication to TLS, a feature re-designed in TLS 1.3. The "PSK identity hint" defined in , which is used by the server to help the client in selecting which PSK identity to use, is, however, not available anymore in TLS 1.3.
• Finally, ciphersuites were depreciated and the RSA-based key transport is not supported in TLS 1.3. As a consequence, only a Diffie-Hellman-based key exchange is available for non-PSK-based authentication. (For PSK-based authentication the use of Diffie-Hellman is optional.)

The profiles in this specification are designed to be adaptable to the broad spectrum of IoT applications, from low-power consumer devices to large-scale industrial deployments. It provides guidelines for implementing TLS/DTLS 1.3 in diverse networking contexts, including reliable, connection-oriented transport via TCP for TLS, and lightweight, connectionless communication via UDP for DTLS. In particular, DTLS is emphasized for scenarios where low-latency communication is paramount, such as multi-hop mesh networks and low-power wide-area networks, where the amount of data exchanged needs to be minimized. This document offers comprehensive guidance for deploying secure communication in resource-constrained IoT environments. It outlines best practices for configuring TLS/DTLS 1.3 to meet the unique needs of IoT devices, ensuring robust security without overwhelming their limited processing, memory, and power resources. The document aims to facilitate the development of secure and efficient IoT deployments and promote the broad adoption of secure communication standards.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document reuses the terms "SHOULD+", "SHOULD-" and "MUST-" from .

Credential Types TLS/DTLS allow different credential types to be used. These include X.509 certificates and raw public keys, pre-shared keys (PSKs), and passwords. The extensions used in TLS/DTLS differ dependencing on the credential types supported. TLS/DTLS 1.3 supports PSK-based authentication, wherein PSKs can be established via session tickets from prior connections or via some external, out-of-band mechanism. To distinguish the two modes, the former is called resumption PSK and the latter external PSK. For performance reasons the support for resumption PSKs is often found in implementations that use X.509 certificates for authentication. A "plain" PSK-based TLS/DTLS client or server, which only implements support for external PSKs as its long-term credential, MUST implement the following extensions:

• Supported Versions,
• Cookie,
• Server Name Indication (SNI),
• Pre-Shared Key,
• PSK Key Exchange Modes, and
• Application-Layer Protocol Negotiation (ALPN).

For use of external pre-shared keys makes the following recommendation:

• Applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions.

Where possible, the importer interface defined in MUST be used for external PSKs. This ensures that external PSKs used in (D)TLS 1.3 are bound to a specific key derivation function (KDF) and hash function. The SNI extension is discussed in this document and the justification for implementing and using the ALPN extension can be found in . An implementation supporting authentication based on certificates and raw public keys MUST support digital signatures with ecdsa_secp256r1_sha256. A compliant implementation MUST support the key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519. For TLS/DTLS clients and servers implementing raw public keys and/or certificates the guidance for mandatory-to-implement extensions described in Section 9.2 of MUST be followed. Entities deploying IoT devices may select credential types based on security characteristics, operational requirements, cost, and other factors. Consequently, this specification does not prescribe a single credential type but provides guidance on considerations relevant to the use of particular types.

Error Handling TLS 1.3 simplified the Alert protocol but the underlying challenge in an embedded context remains unchanged, namely what should an IoT device do when it encounters an error situation. The classical approach used in a desktop environment where the user is prompted is often not applicable with unattended devices. Hence, it is more important for a developer to find out from which error cases a device can recover from.

Session Resumption TLS 1.3 has built-in support for session resumption by utilizing PSK-based credentials established in an earlier exchange.

 Compression TLS 1.3 does not have support for compression of application data traffic, as offered by previous versions of TLS. Applications are therefore responsible for transmitting payloads that are either compressed or use a more efficient encoding otherwise. With regards to the handshake itself, various strategies have been applied to reduce the size of the exchanged payloads. TLS and DTLS 1.3 use less overhead, depending on the type of key confirmations, when compared to previous versions of the protocol. Additionally, the work on Compact TLS (cTLS) has taken compression of the handshake a step further by utilizing out-of-band knowledge between the communication parties to reduce the amount of data to be transmitted at each individual handshake, among applying other techniques.

 Forward Secrecy RFC 8446 has removed Static RSA and Static Diffie-Hellman cipher suites, therefore all public-key-based key exchange mechanisms available in TLS 1.3 provide forward secrecy. Pre-shared keys (PSKs) can be used with (EC)DHE key exchange to provide forward secrecy or can be used alone, at the cost of losing forward secrecy for the application data.

Authentication and Integrity-only Cipher Suites For a few, very specific Industrial IoT use cases defines two cipher suites that provide data authenticity, but not data confidentiality. Please review the security and privacy considerations about their use detailed in .

Keep-Alive The discussion in Section 10 of is applicable.

Timers and ACKs Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS 1.3 ACKs sensibly decrease the risk of congestion collapse which was the basis for the very conservative recommendations given in . In general, the recommendations in regarding ACKs apply. In particular, "(w)hen DTLS 1.3 is used in deployments with lossy networks, such as low-power, long-range radio networks as well as low-power mesh networks, the use of ACKs is recommended" to signal any sign of disruption or lack of progress. This allows for selective or early retransmission, which leads to more efficient use of bandwidth and memory resources. Due to the vast range of network technologies used in IoT deployments, from wired LAN to GSM-SMS, it's not possible to provide a universal recommendation for an initial timeout. Therefore, it is RECOMMENDED that DTLS 1.3 implementations allow developers to explicitly set the initial timer value. Developers SHOULD set the initial timeout to be twice the expected round-trip time (RTT), but no less than 1000ms. For specific application/network combinations, a sub-second initial timeout MAY be set. In cases where no RTT estimates are available, a 1000ms initial timeout is suitable for the general Internet. For RRC, the recommendations in apply. Just like the handshake initial timers, it is RECOMMENDED that DTLS 1.2 and 1.3 implementations offer an option for their developers to explicitly set the RRC timer.

 Random Number Generation The discussion in Section 12 of is applicable with one exception: the ClientHello and the ServerHello messages in TLS 1.3 do not contain gmt_unix_time component anymore.

Server Name Indication This specification mandates the implementation of the Server Name Indication (SNI) extension. Where privacy requirements require it, the ECH (Encrypted Client Hello) extension prevents an on-path attacker to determine the domain name the client is trying to connect to. Since the Encrypted Client Hello extension requires use of Hybrid Public Key Encryption (HPKE) and additional protocols require further protocol exchanges and cryptographic operations, there is a certain overhead associated with this privacy feature. Note that in industrial IoT deployments the use of ECH may be disabled because network administrators inspect the SNI to detect malicious behaviour. Besides, to avoid leaking DNS lookups from network inspection altogether further protocols are needed, including DNS-over-HTTPS (DoH) , DNS-over-TLS (DoT) and DNS-over-QUIC (DoQ) .

 Maximum Fragment Length Negotiation The Maximum Fragment Length Negotiation (MFL) extension has been superseded by the Record Size Limit (RSL) extension . Implementations in compliance with this specification MUST implement the RSL extension and SHOULD use it to indicate their RAM limitations.

Crypto Agility The recommendations in Section 19 of are applicable.

Key Length Recommendations The recommendations in Section 20 of are applicable.

0-RTT Data establishes that:

• Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT.

At the time of writing, no such profile has been defined for CoAP . Therefore, 0-RTT MUST NOT be used by CoAP applications.

Certificate Profile This section contains updates and clarifications to the certificate profile defined in . The content of Table 1 of has been split by certificate "type" in order to clarify exactly what requirements and recommendations apply to which entity in the PKI hierarchy. A Device Identifier (DevID) consists of:

• a private key,
• a certificate containing the public key and the identifier certified by the certificate issuer, and
• a certificate chain leading up to a trust anchor (typically the root certificate).

The IEEE 802.1AR specification introduces the concept of DevIDs and defines two specialized versions:

• Initial Device Identifiers (IDevIDs): Provisioned during manufacturing to provide a unique, stable identity for the lifetime of the device.
• Locally Significant Device Identifiers (LDevIDs): Provisioned after deployment and typically used for operational purposes within a specific domain.

Thus, IDevIDs and LDevIDs are specialized forms of DevIDs as defined in IEEE 802.1AR. The IDevID is typically provisioned by a manufacturer and signed by the manufacturer CA. It is then used to obtain operational certificates, the LDevIDs, from the operator or owner of the device. Some protocols also introduce an additional hierarchy with application instance certificates, which are obtained for use with specific applications. IDevIDs are primarily used with device onboarding or bootstrapping protocols, such as the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol or by LwM2M Bootstrap . Hence, the use of IDevIDs is limited on purpose even though they have a long lifetime, or do not expire at all. While some bootstrapping protocols use TLS (and therefore make use of the IDevID as part of client authentication) there are other bootstrapping protocols that do not use TLS/DTLS for client authentication, such as FIDO Device Onboarding (FDO) . In many cases, a profile for the certificate content is provided by those specifications. For these reasons, this specification focuses on the description of LDevIDs. This document uses the terminology and some of the rules for populating certificate content defined in IEEE 802.1AR. However, this specification does not claim conformance to IEEE 802.1AR. since such a compliance statement goes beyond the use of the terminology and the certificate content and would include the use of management protocols, fulfillment of certain hardware security requirements, and interfaces to access these hardware security modules. Placing these requirements on network equipment like routers may be appropriate but designers of constrained IoT devices have opted for different protocols and hardware security choices.

All Certificates To avoid repetition, this section outlines requirements on X.509 certificates applicable to all PKI entities.

Version Certificates MUST be of type X.509 v3. Note that TLS 1.3 allows to convey payloads other than X.509 certificates in the Certificate message. The description in this section only focuses on X.509 v3 certificates and leaves the description of other formats to other sections or even other specifications.

Serial Number CAs MUST generate non-sequential serial numbers greater than or equal to eight (8) octets from a cryptographically secure pseudo-random number generator. limits this field to a maximum of 20 octets. The serial number MUST be unique for each certificate issued by a given CA (i.e., the issuer name and the serial number uniquely identify a certificate). This requirement is aligned with .

Signature The signature MUST be ecdsa-with-SHA256 or stronger . Note: In contrast to IEEE 802.1AR this specification does not require end entity certificates, subordinate CA certificates, and CA certificates to use the same signature algorithm. Furthermore, this specification does not utilize RSA for use with constrained IoT devices and networks.

Issuer The issuer field MUST contain a non-empty distinguished name (DN) of the entity that has signed and issued the certificate in accordance with .

 Validity Vendors must determine the expected lifespan of their IoT devices. This decision directly affects how long firmware and software updates are provided for, as well as the level of maintenance that customers can expect. It also affects the maximum validity period of certificates. In most IoT deployments, IDevIDs are provisioned with an unlimited lifetime as per . For this purpose, a special value for the notAfter date field, the GeneralizedTime value of 99991231235959Z, is utilized. This special value was introduced in . When this is done, then the CA certificates and the certificates of subordinate CAs have a maximum validity period. Therefore, careful consideration is required as to whether it is appropriate to issue IDevID certificates with no maximum validity period. LDevID certificates are, however, issued by the operator or owner, and may be renewed at a regular interval using protocols, such as Enrollment over Secure Transport (EST) or the Certificate Management Protocol (CMP) . It is therefore RECOMMENDED to limit the lifetime of these LDevID certificates using the notBefore and notAfter fields, as described in Section 4.1.2.5 of . Values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds even where the number of seconds is zero. Note that the validity period is defined as the period of time from notBefore through notAfter, inclusive. This means that a hypothetical certificate with a notBefore date of 9 June 2021 at 03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes valid at the beginning of the :01 second, and only becomes invalid at the :02 second, a period that is 90 days plus 1 second. So for a 90-day, notAfter must actually be 03:42:00. For devices without a reliable source of time we advise the use of a device management solution, which typically includes a certificate management protocol, to manage the lifetime of all the certificates used by the device. While this approach does not utilize certificates to its widest extent, it is a solution that extends the capabilities offered by a raw public key approach.

 Subject Public Key Info The subjectPublicKeyInfo field indicates the algorithm and any associated parameters for the ECC public key. This profile uses the id-ecPublicKey algorithm identifier for ECDSA signature keys, as defined and specified in . This specification assumes that devices supported one of the following algorithms:

• id-ecPublicKey with secp256r1,
• id-ecPublicKey with secp384r1, and
• id-ecPublicKey with secp521r1.

There is no requirement to use CA certificates and certificates of subordinate CAs to use the same algorithm as the end entity certificate. Certificates with longer lifetime may well use a cryptographic stronger algorithm.

Certificate Revocation Checks The Certificate Revocation Lists (CRLs) distribution points extension has been defined in RFC 5280 to identify how CRL information is obtained. The authority information access extension indicates how to access information like the online certificate status service (OCSP). Both extensions SHOULD NOT be set. If set, they MUST NOT be marked critical. Instead of using CRLs or OCSP this document follows the guidance in : for certificate revocation, neither OCSP nor CRL are used by constrained IoT devices. The use of device management protocols for IoT devices, which often include an onboarding or bootstrapping mechanism, has also seen considerable uptake in deployed devices. These protocols, some of which are standardized, allow for the distribution and updating of certificates on demand. An example of a standardized IoT device management protocol is the Lightweight Machine-to-Machine (LwM2M) protocol. Device management protocols enable a deployment model where IoT devices utilize end entity certificates with shorter lifetime making certificate revocation protocols, like OCSP and CRLs, less relevant. Whenever certificates are updated the TLS stack needs to be informed since the communication endpoints need to be aware of the new certificates. This is particularly important when long-lived TLS connections are used. In such a case, the post-handshake authentication exchange is triggered when the application requires it. TLS 1.3 provides client-to-server post-handshake authentication only. Mutual authentication via post-handshake messages is available by the use of the "Exported Authenticator" but requires the application layer protocol to carry the payloads. Hence, instead of performing certificate revocation checks on the IoT device itself this it is RECOMMENDED to delegate this task to the IoT device operator and to take the necessary action to allow IoT devices to remain operational.

Root CA Certificate This section outlines the requirements for root CA certificates.

Subject mandates that Root CA certificates MUST have a non-empty subject field. The subject field MUST contain the commonName, the organizationName, and the countryName attribute and MAY contain an organizationalUnitName attribute.

Authority Key Identifier Section 4.2.1.1 of defines the Authority Key Identifier as follows: "The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys." The Authority Key Identifier extension MAY be omitted. If it is set, it MUST NOT be marked critical, and MUST contain the subjectKeyIdentifier of this certificate.

Subject Key Identifier defines the SubjectKeyIdentifier as follows: "The subject key identifier extension provides a means of identifying certificates that contain a particular public key." The Subject Key Identifier extension MUST be set, MUST NOT be marked critical, and MUST contain the key identifier of the public key contained in the subject public key info field. The subjectKeyIdentifier is used by path construction algorithms to identify which CA has signed a subordinate certificate.

Key Usage defines the key usage field as follows: "The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate." The Key Usage extension MAY be set. If it is set, it MUST be marked critical and the keyCertSign or cRLSign purposes MUST be set. Additional key usages MAY be set depending on the intended usage of the public key. defines the extended key usage as follows: "This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension." This extendedKeyUsage extension MUST NOT be set in CA certificates.

Basic Constraints states that "The Basic Constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate. The cA boolean indicates whether the certified public key may be used to verify certificate signatures." For the pathLenConstraint RFC 5280 makes further statements:

• "The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit. In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path."
• "A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path."
• "Where pathLenConstraint does not appear, no limit is imposed."
• "Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates."

The Basic Constraints extension MUST be set, MUST be marked critical, the cA flag MUST be set to true and the pathLenConstraint MUST be omitted.

Subordinate CA Certificate This section outlines the requirements for subordinate CA certificates.

Subject The subject field MUST be set and MUST contain the commonName, the organizationName, and the countryName attribute and MAY contain an organizationalUnitName attribute.

Authority Key Identifier The Authority Key Identifier extension MUST be set, MUST NOT be marked critical, and MUST contain the subjectKeyIdentifier of the CA that issued this certificate.

Subject Key Identifier The Subject Key Identifier extension MUST be set, MUST NOT be marked critical, and MUST contain the key identifier of the public key contained in the subject public key info field.

Key Usage The Key Usage extension MUST be set, MUST be marked critical, the keyCertSign or cRLSign purposes MUST be set, and the digitalSignature purpose SHOULD be set. Subordinate certification authorities SHOULD NOT have any extendedKeyUsage. reserves EKUs to be meaningful only in end entity certificates.

Basic Constraints The Basic Constraints extension MUST be set, MUST be marked critical, the cA flag MUST be set to true and the pathLenConstraint SHOULD be omitted.

CRL Distribution Point The CRL Distribution Point extension SHOULD NOT be set. If it is set, it MUST NOT be marked critical and MUST identify the CRL relevant for this certificate.

Authority Information Access The Authority Information Access extension SHOULD NOT be set. If it is set, it MUST NOT be marked critical and MUST identify the location of the certificate of the CA that issued this certificate and the location it provides an online certificate status service (OCSP).

End Entity Certificate This section outlines the requirements for end entity certificates.

Subject This section describes the use of end entity certificate primarily for (D)TLS clients running on IoT devices. Operating (D)TLS servers on IoT devices is possible but less common. mandates that the subject field not be used to identify a service. However, certain IoT applications (for example, , ) use the subject field to encode the device serial number. The requirement in to only use EUI-64 for end entity certificates as a subject field is lifted. Two fields are typically used to encode a device identifier, namely the Subject and the subjectAltName fields. Protocol specifications tend to offer recommendations about what identifiers to use and the deployment situation is fragmented. The subject field MAY include a unique device serial number. If the serial number is included, it MUST be encoded in the X520SerialNumber attribute. e.g., use requires a serial number in IDevID certificates. defines: "The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate." The subject alternative name extension MAY be set. If it is set, it MUST NOT be marked critical, except when the subject DN contains an empty sequence. If the EUI-64 format is used to identify the subject of an end entity certificate, it MUST be encoded as a Subject DN using the X520SerialNumber attribute. The contents of the field is a string of the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the symbols '0'-'9' or 'A'-'F'. Per domain names MUST NOT be encoded in the subject commonName. Instead they MUST be encoded in a subjectAltName of type DNS-ID. Domain names MUST NOT contain wildcard (*) characters. The subjectAltName MUST NOT contain multiple names. Note: The IEEE 802.1AR recommends to encode information about a Trusted Platform Module (TPM), if present, in the HardwareModuleName (). This specification does not follow this recommendation. Where IoT devices are accepting (D)TLS connections, i.e., they are acting as a server, it is unlikely that there will be a useful name that can go into the SNI. In general, the use of SNI for the purpose of virtual hosting on constrained IoT devices is rare. The IoT device cannot depend on a client providing a correct SNI, and so it MUST ignore the extension. This implies that IoT devices cannot do name-based virtual hosting of TLS connections. In the unlikely event that an IoT device has multiple servers responding with different server certificate, then the server SHOULD use different IP addresses or port numbers.

Authority Key Identifier The Authority Key Identifier extension MUST be set, MUST NOT be marked critical, and MUST contain the subjectKeyIdentifier of the CA that issued this certificate.

Subject Key Identifier The Subject Key Identifier MUST NOT be included in end entity certificates, as it can be calculated from the public key, so it just takes up space. End entity certificates are not used in path construction, so there is no ambiguity regarding which certificate chain to use, as there can be with subordinate CAs.

Key Usage The key usage extension MUST be set and MUST be marked as critical. For signature verification keys the digitialSignature key usage purpose MUST be specified. Other key usages are set according to the intended usage of the key. If enrollment of new certificates uses server-side key generation, encrypted delivery of the private key is required. In such cases the key usage keyEncipherment or keyAgreement MUST be set because the encrypted delivery of the newly generated key involves encryption or agreement of a symmetric key. On-device key generation is, however, the preferred approach. As specified in , the extendedKeyUsage SHOULD NOT be present in IDevID certificates, as it reduces the utility of the IDevID. For locally assigned LDevID certificates to be usable with TLS, the extendedKeyUsage MUST contain at least one of the following: id-kp-serverAuth or id-kp-clientAuth.

Update of Trust Anchors Since the publication of RFC 7925 the need for firmware update mechanisms has been reinforced and the work on standardizing a secure and interoperable firmware update mechanism has made substantial progress, see . RFC 7925 recommends to use a software / firmware update mechanism to provision devices with new trust anchors. This approach only addresses the distribution of trust anchors and not end entity certificates or certificates of subordinate CAs. As an alternative, certificate management protocols like CMP and EST have also offered ways to update trust anchors. See, for example, for an approach to obtaining CA certificates via EST.

Certificate Overhead In a public key-based key exchange, certificates and public keys are a major contributor to the size of the overall handshake. For example, in a regular TLS 1.3 handshake with minimal ECC certificates and no subordinate CA utilizing the secp256r1 curve with mutual authentication, around 40% of the entire handshake payload is consumed by the two exchanged certificates. Hence, it is not surprising that there is a strong desire to reduce the size of certificates and certificate chains. This has led to various standardization efforts. Below is a brief summary of what options an implementer has to reduce the bandwidth requirements of a public key-based key exchange. Note that many of the standardized extensions are not readily available in TLS/DTLS stacks since optimizations typically get implemented last.

• Use elliptic curve cryptography (ECC) instead of RSA-based certificate due to the smaller certificate size. This document recommends the use of elliptic curve cryptography only.
• Avoid deep and complex CA hierarchies to reduce the number of subordinate CA certificates that need to be transmitted and processed. See for a discussion about CA hierarchies. Most security requirements can be satisfied with a PKI depth of 3 (root CA, one subordinate CA, and end entity certificates).
• Pay attention to the amount of information conveyed inside certificates.
• Use session resumption to reduce the number of times a full handshake is needed. Use Connection IDs , when possible, to enable long-lasting connections.
• Use the TLS cached info extension to avoid sending certificates with every full handshake.
• Use client certificate URLs instead of full certificates for clients. When applications perform TLS client authentication via DNS-Based Authentication of Named Entities (DANE) TLSA records then the specification may be used to reduce the packets on the wire. Note: The term "TLSA" does not stand for anything; it is just the name of the RRtype, as explained in .
• Use certificate compression as defined in .
• Use alternative certificate formats, where possible, such as raw public keys or CBOR-encoded certificates .

The use of certificate handles, as introduced in cTLS , is a form of caching or compressing certificates as well. Although the TLS specification does not explicitly prohibit a server from including trust anchors in the Certificate message - and some implementations do - trust anchors SHOULD NOT be transmitted in this way. Trust anchors are intended to be provisioned through out-of-band mechanisms, and any trust anchor included in the TLS Certificate message cannot be assumed trustworthy by the client. Including them therefore serves no functional purpose and unnecessarily consumes bandwidth. However, due to limited or asymmetric knowledge between client and server, omitting trust anchors entirely is not always straightforward. Several scenarios highlight this challenge:

• Pinned Server Certificates: In many device-to-cloud deployments (see ), clients pin a specific server certificate. If the client has pinned the server certificate, retransmitting it is unnecessary - but the server cannot reliably determine this.
• Root Key Transitions: During root key rollover events (see ), new trust anchors may not yet be fully distributed across all devices. This is especially relevant in device-to-device communication ), where server roles are determined dynamically and trust anchor distribution may be inconsistent.
• Non-Root Trust Anchors: In some deployments, the client’s trust anchor may be an intermediate CA rather than a root certificate. The server, lacking knowledge of the client’s trust store, cannot always select a certificate chain that aligns with the client’s trust anchor. To mitigate this, the client MAY include the Trusted CA Indication extension (see ) in its ClientHello to signal the set of trust anchors it supports.

assumes the presence of a shared directory service for certificate retrieval. In constrained or isolated IoT environments, this assumption does not hold. Trust anchors are often distributed via firmware updates or fetched periodically using certificate management protocols, such as EST (e.g., the /cacerts endpoint). To support transitional trust states during trust anchor updates, devices MUST handle both:

• newWithOld: a certificate where the new trust anchor is signed by the old one, enabling communication with peers that have not yet received the update.
• oldWithNew: a certificate where the old trust anchor is signed by the new one, enabling verification of peers that still rely on the older anchor.

These certificates may be presented as an unordered set, and devices may not be able to distinguish their roles without additional metadata. Although the TLS specification does not forbid a server from including trust anchors in the Certificate message, and some implementations do so, trust anchors SHOULD NOT be transmitted this way. Trust anchors are meant to be provisioned out of band, and any trust anchor sent in the Certificate message cannot be relied upon by the client. Sending it therefore only wastes bandwidth. A complication arises when the client’s trust anchor is not a widely trusted root CA. In that case, the server cannot determine in advance which trust anchors the client has. To address this, the client MAY include the Trusted CA Indication extension in its ClientHello to signal the set of trust anchors it supports, allowing the server to select an appropriate certificate chain. Whether to utilize any of the above extensions or a combination of them depends on the anticipated deployment environment, the availability of code, and the constraints imposed by already deployed infrastructure (e.g., CA infrastructure, tool support).

Ciphersuites According to , the use of AES-CCM with 8-octet authentication tags (CCM_8) is considered unsuitable for general use with DTLS. This is because it has low integrity limits (i.e., high sensitivity to forgeries) which makes endpoints that negotiate ciphersuites based on such AEAD vulnerable to a trivial DoS attack. See also Sections and of for further discussion on this topic, as well as references to the analysis supporting these conclusions. Specifically, warns that: TLS_AES_128_CCM_8_SHA256 MUST NOT be used in DTLS without additional > safeguards against forgery. Implementations MUST set usage limits for > AEAD_AES_128_CCM_8 based on an understanding of any additional forgery > protections that are used. ]]> Since all the ciphersuites required by and rely on CCM_8, there is no alternate ciphersuite available for applications that aim to eliminate the security and availability threats related to CCM_8 while retaining interoperability with the larger ecosystem. In order to ameliorate the situation, it is RECOMMENDED that implementations support the following two ciphersuites for TLS 1.3:

• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM

and offer them as their first choice. These ciphersuites provide confidentiality and integrity limits that are considered acceptable in the most general settings. For the details on the exact bounds of both ciphersuites see . Note that the GCM-based ciphersuite offers superior interoperability with cloud services at the cost of a slight increase in the wire and peak RAM footprints. When the GCM-based ciphersuite is used with TLS 1.2, the recommendations in related to deterministic nonce generation apply. In addition, the integrity limits on key usage detailed in also apply. summarizes the recommendations regarding ciphersuites: TLS 1.3 Ciphersuite Requirements

Ciphersuite	MTI Requirement
TLS_AES_128_CCM_8_SHA256	MUST-
TLS_AES_128_CCM	SHOULD+
TLS_AES_128_GCM_SHA256	SHOULD+

Fault Attacks on Deterministic Signature Schemes A number of passive side-channel attacks as well as active fault-injection attacks (e.g., ) have been demonstrated to be successful in allowing a malicious third party to gain information about the signing key if a fully deterministic signature scheme (e.g., ECDSA or EdDSA ) is used. Most of these attacks assume physical access to the device and are therefore especially relevant to smart cards as well as IoT deployments with poor or non-existent physical security. In this security model, it is recommended to combine both randomness and determinism, for example, as described in .

Post-Quantum Cryptography (PQC) Considerations As detailed in , the IETF is actively working to address the challenges of adopting PQC in various protocols, including TLS. The document highlights key aspects engineers must consider, such as algorithm selection, performance impacts, and deployment strategies. It emphasizes the importance of gradual integration of PQC to ensure secure communication while accounting for the increased computational, memory, and bandwidth requirements of PQC algorithms. These challenges are especially relevant in the context of IoT, where device constraints limit the adoption of larger key sizes and more complex cryptographic operations . Besides, any choice need to careful evaluate the associated energy requirements . Incorporating PQC into TLS is still ongoing, with key exchange message sizes increasing due to larger public keys. These larger keys demand more flash storage and higher RAM usage, presenting significant obstacles for resource-constrained IoT devices. The transition from classical cryptographic algorithms to PQC will be a significant challenge for constrained IoT devices, requiring careful planning to select hardware suitable for the task considering the lifetime of an IoT product.

Open Issues A list of open issues can be found at https://github.com/thomas-fossati/draft-tls13-iot/issues

Security Considerations This entire document is about security.

IANA Considerations This document makes no requests to IANA.

References Normative References This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. University of Applied Sciences Bonn-Rhein-Sieg Linaro This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Implementations offering the CID functionality described in RFC 9146 and RFC 9147 are encouraged to also provide the return routability check functionality described in this document. For this reason, this document updates RFC 9146 and RFC 9147. An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document updates RFC 3279 to specify algorithm identifiers and ASN.1 encoding rules for the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the Internet X.509 PKI. [STANDARDS-TRACK] This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Informative References This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context. The new ciphertext record format with the CID also provides content type encryption and record layer padding. This document updates RFC 6347. The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK] The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice. This document offers guidance to engineers designing Internet- connected smart objects. This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. Industrial Systems Institute, R.C. ATHENA, Patras, Greece Industrial Systems Institute, R.C. ATHENA & Electrical and Computer Engineering, Dpt, University of Patras, Patras, Greece Industrial Systems Institute, R.C. ATHENA, Patras, Greece CSIRO's Data61 Sydney, Australia Monash University, Melbourne, Australia Monash University, Melbourne, Australia ACM Springer International Publishing The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. IEEE FIDO Alliance OMA SpecWorks OMA SpecWorks Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. [STANDARDS-TRACK] This document describes a mechanism that builds on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. Apple Akamai This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK] The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client. [STANDARDS-TRACK] Windy Hill Systems, LLC Cisco Meta Platforms, Inc. This document specifies a "compact" version of TLS 1.3 and DTLS 1.3. It saves bandwidth by trimming obsolete material, tighter encoding, a template-based specialization technique, and alternative cryptographic techniques. cTLS is not directly interoperable with TLS 1.3 or DTLS 1.3 since the over-the-wire framing is different. A single server can, however, offer cTLS alongside TLS or DTLS. This document defines the use of cipher suites for TLS 1.3 based on Hashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced-security mechanism that provides authentication and message integrity without supporting confidentiality. Independent Fastly Cryptography Consulting LLC Cloudflare This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni). This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. Sandelman Software Works vanderstok consultancy Cisco Systems IoTconsultancy.nl This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK] Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. Sandelman Software Works This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information. Salesforce OpenSSL Corporation This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records. Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. Ericsson AB Ericsson AB RISE AB RISE AB IN Groupe This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates by over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Ericsson Ericsson Ericsson Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security does not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend hedged constructions in deployments where side- channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators.

Acknowledgments We would like to thank Henk Birkholz, Hendrik Brockhaus, Ben Kaduk, John Mattsson, Daniel Migault, Rich Salz, and Marco Tiloca.

Contributors