]> TLS/DTLS 1.3 Profiles for the Internet of Things University of the Bundeswehr Munich
Neubiberg Bavaria 85577 Germany hannes.tschofenig@gmx.net
NVIDIA
tfossati@nvidia.com
Sandelman Software Works
mcr+ietf@sandelman.ca
Ericsson
Canada daniel.migault@ericsson.com
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 no longer applicable to the new version of TLS/DTLS. 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 authentication (client-to-server). 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 placeholder message.
  • introduced PSK-based authentication to TLS, including the "PSK identity hint", which allowed a server to help the client select a PSK identity. TLS 1.3 removed this separate server-provided hint. Instead, the client offers one or more PSK identities in the pre_shared_key extension, and the server selects one of them as part of the handshake. As a result, TLS 1.3 clients need sufficient local or application-provided context, such as the intended server name, the application protocol, or local configuration, to determine which PSK identities to offer.
  • Finally, ciphersuites were deprecated 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 (i.e., certificate-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. This document updates with respect to the X.509 certificate profile () and ciphersuite requirements (). The update is intentionally limited. remains the TLS/DTLS 1.2 profile for constrained IoT devices and is still relevant for legacy deployments. This is particularly important in industrial IoT deployments, where devices, certification programs, and operational processes often have long lifecycles and therefore transition to newer protocol versions more slowly than general-purpose Internet software. This document does not replace the TLS/DTLS 1.2 protocol guidance in . Instead, it defines the corresponding TLS/DTLS 1.3 profile and updates only those requirements that need to change for TLS/DTLS 1.3 deployments, namely the certificate profile and ciphersuite recommendations. This document is organized as follows. The sections from through profile TLS/DTLS credentials and protocol features relevant to constrained IoT deployments, including credential types, session resumption, forward secrecy, server name indication (SNI), record sizing, crypto agility, key lengths, and 0-RTT data. updates and clarifies the X.509 certificate profile from . TLS protocol compatibility is a required basis, but it is insufficient to permit interoperability at the level of authentication and authorization. and discuss trust-anchor update and certificate-size overhead. updates the ciphersuite requirements. The remaining sections discuss fault attacks, post-quantum cryptography, privacy, and security considerations.
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 uses TLS terminology from , DTLS terminology from , and X.509 certificate and certification path terminology from . IoT device-class terminology follows and . The DevID, IDevID, and LDevID terms used in the certificate profile are introduced in and described in .
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 depending on the credential types supported. Self-signed X.509 certificates are still X.509, not raw public keys; raw public keys are conveyed via the raw_public_key extension . When raw public keys are used for peer authentication, deployments need to bind the authenticated key to the expected peer identity. describes misbinding attacks in such deployments and identifies mitigations, including the validation of the server_name extension where a domain name is used. Password-authenticated key exchange (PAKE) mechanisms allow two endpoints to authenticate and establish keys from a low-entropy shared secret, such as a user-entered password, without using that secret directly as a TLS PSK. Such mechanisms have been defined for earlier versions of TLS, and new work is underway to add PAKE authentication to TLS 1.3 . The deployment model for PAKE mechanisms in constrained IoT environments is still evolving. This profile therefore does not cover password-authenticated TLS deployments. This profile considers three authentication modes for IoT devices: (1) certificate-based, (2) raw public key-based and (3) external PSK-based. TLS/DTLS 1.3 supports both PSK-only and PSK with (EC)DHE key exchange modes. For PSK use, endpoints MUST use (EC)DHE where possible to provide forward secrecy. PSK-only is acceptable when the loss of forward secrecy is explicitly accepted for the IoT deployment; see . 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. Implementations that only support external PSKs are common in constrained devices; implementations using certificates often also support resumption PSKs for performance. Endpoints that use external PSKs as their only long-term credential still follow the TLS/DTLS 1.3 extension requirements according to their applicability; see . This profile differs from certificate-based and raw-public-key-based deployments only in that endpoints that exclusively support external PSK authentication do not need to implement certificate-authentication extensions or signature algorithm support. When such endpoints offer or negotiate psk_dhe_ke, the supported_groups and key_share extensions are required as specified by TLS 1.3. When psk_ke is used without (EC)DHE, those extensions are not needed for that handshake. For external pre-shared keys, recommends that applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions. Additional guidance for using external PSKs in TLS, including PSK entropy requirements and security properties, is provided by . 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. 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. Entities deploying IoT devices may select credential types based on security characteristics, operational requirements, cost, and other factors. Consequently, this specification does not mandate a single credential type but provides guidance on considerations relevant to the use of particular types. TLS/DTLS 1.3 implementations conforming to this profile MUST follow the mandatory-to-implement extension requirements in . For constrained IoT implementations, it is useful to have a single checklist that maps TLS/DTLS 1.3 extension support to the credential modes and deployment features used by this profile. provides that implementation checklist. It summarizes the TLS/DTLS 1.3 requirements and the additional extension requirements established by this profile; it does not replace the normative requirements in the referenced sections. Mandatory and Profile-Specific Extension Requirements
Extension Applicability Reference
supported_versions TLS/DTLS 1.3 negotiation
cookie HelloRetryRequest and DTLS use
signature_algorithms Certificate authentication and other signature-based authentication mechanisms
signature_algorithms_cert Certificate authentication where certificate signature algorithms are negotiated separately
supported_groups DHE/ECDHE key exchange, including psk_dhe_ke
key_share DHE/ECDHE key exchange, including psk_dhe_ke
server_name Applications capable of using SNI
pre_shared_key PSK authentication and resumption
psk_key_exchange_modes PSK authentication and resumption
application_layer_protocol_negotiation Application protocol selection
record_size_limit Constrained endpoints
Error Handling TLS 1.3 simplified the Alert protocol, but IoT deployments still need explicit error-handling behavior above the TLS library. This is particularly important in Industrial IoT applications where safety, availability, and deterministic behavior are high priorities. Unattended devices often cannot rely on prompting a user or on generic TLS-library defaults. Applications therefore need code and policy for handling relevant TLS errors, including deciding which errors are recoverable, when to retry or re-establish a connection, when to use an alternative endpoint or credential, and when to enter a safe operational state. The general guidance in continues to apply. However, implementations using TLS 1.3 MUST follow the alert definitions and processing rules in . TLS 1.2-specific alerts for features that no longer exist in TLS 1.3, such as decompression_failure and no_renegotiation, are not used in TLS 1.3. TLS 1.3 also defines alerts such as missing_extension for protocol violations involving required extensions.
Session Resumption TLS 1.3 has built-in support for session resumption by utilizing PSK-based credentials established in an earlier exchange. Session resumption can substantially reduce bandwidth, latency, and cryptographic computation in IoT deployments because subsequent handshakes do not need to repeat the full certificate-based authentication exchange. Servers can issue resumption PSKs in a way that matches the expected reconnection pattern of the deployment. The number of tickets issued, their lifetime, and their reuse policy are deployment decisions that balance availability and bandwidth savings against server state, anti-replay requirements, and privacy considerations.
 Forward Secrecy RFC 9846 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. For PSK use, endpoints SHOULD use (EC)DHE to achieve forward secrecy. PSK-only is acceptable only when the loss of forward secrecy is explicitly accepted for the IoT deployment. TLS 1.3 KeyUpdate refreshes application traffic keys, but it does not inject fresh key exchange input and therefore does not provide post-compromise security for a long-lived session. Industrial IoT deployments can have long-lived TLS or DTLS associations where reconnecting is operationally undesirable. The Extended Key Update mechanism is being developed for such cases; it performs a fresh key exchange inside an active TLS/DTLS 1.3 session and can provide post-compromise security when the deployment requires it and both peers support the extension.
Keep-Alive The discussion in is applicable. When a TLS/DTLS-level keep-alive or path MTU discovery mechanism is needed, use of the Heartbeat Extension defined in is RECOMMENDED.
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 . The recommendations in regarding ACKs apply. In particular,
When 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.
ACKs provide explicit feedback on which handshake messages have been received. This enables endpoints to detect a lack of progress more quickly and to trigger selective or early retransmission, leading to more efficient use of bandwidth and memory. 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, which is a conservative default aligned with the guidance in . 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. Regarding the timers used by the Return Routability Check (RRC) functionality, 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 is applicable with one exception: the ClientHello and the ServerHello messages in TLS 1.3 do not contain gmt_unix_time component anymore. For entropy generation and randomness considerations, implementers should also consult .
Server Name Indication TLS 1.3 requires implementations to support the Server Name Indication (SNI) extension when used with applications capable of using it (). IoT clients SHOULD send SNI when connecting to a named service, in particular when the peer is a cloud service, a multi-tenant endpoint, or any server that uses SNI for certificate or application-context selection. IoT clients MAY omit SNI when the peer identity is established by other application-specific configuration, such as a configured IP address and port, a pinned certificate, a raw public key, or an external PSK identity. When no domain name is used, SNI is not applicable. When SNI is omitted in deployments using raw public keys or self-signed certificates, the application needs another binding between the authenticated key and the expected peer identity. Otherwise, the deployment can be vulnerable to the misbinding attacks described in . Deployments that require confidentiality of SNI and other ClientHello metadata can use Encrypted ClientHello (ECH) . ECH is most applicable to IoT deployments that use named cloud services or shared service infrastructure and have explicit privacy requirements. Since ECH does not protect DNS lookups or other metadata outside the TLS handshake, deployments that rely on ECH for privacy also need to protect DNS resolution, for example using encrypted DNS mechanisms; see for IoT-specific DNS guidance. The applicability, deployment requirements, and limitations of ECH are described in . IoT servers MAY use SNI for certificate or application-context selection. Authorization decisions are outside the scope of SNI and are based on the authenticated peer credentials and local policy. If constrained clients are not expected to send useful SNI values, deployments SHOULD prefer separate IP addresses or port numbers when different server identities or certificates need to be distinguished.
Application-Layer Protocol Negotiation The Application-Layer Protocol Negotiation (ALPN) extension is independent of the credential type used for TLS authentication. Implementations conforming to this profile MUST support ALPN. Endpoints SHOULD use ALPN when more than one application protocol, application protocol version, or application context can be served by the same TLS endpoint, certificate, raw public key, or PSK identity. When a deployment is restricted by configuration to a single application protocol, ALPN MAY be omitted. Use of ALPN helps prevent cross-protocol confusion attacks and follows the guidance in .
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 MUST use it to indicate their RAM or record-size limitations unless the default record sizes, which require approximately 18 KB of memory for TLS 1.3 ciphertext and associated processing buffers, are acceptable for the IoT deployment.
Crypto Agility The recommendations in are applicable. The third bullet point in that section anticipated the evolution of cryptographic hardware support in IoT devices. Today, chip manufacturers commonly provide hardware acceleration for AES-CCM, as well as for other AES modes, including AES-GCM. Note that the ciphersuite recommendations in this document now include GCM, in addition to CCM, as described in .
Key Length Recommendations The recommendations in apply with the following update. The recommendation for 112 bits of security strength, described there as equivalent to a 112-bit symmetric key and a 233-bit ECC key, is raised to at least 128 bits of security strength. Using the comparison in RFC 7925, this corresponds to a 128-bit symmetric key and a 283-bit ECC key. For the prime-field curves used by this profile, secp256r1 provides the intended 128-bit security strength. This update is consistent with the transition to 128-bit security strength discussed in .
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.
For any application protocol, 0-RTT MUST NOT be used unless a protocol-specific profile exists. At the time of writing, no such profile has been defined for commonly used IoT application protocols such as CoAP or MQTT (Message Queuing Telemetry Transport). Therefore, this profile does not enable 0-RTT for CoAP, MQTT, or other IoT application protocols that lack a protocol-specific 0-RTT profile.
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 the certificates that make up a certification path from a trust anchor to an end entity certificate. This profile does not define a specific certificate policy OID; deployments MAY define one if needed for local policy enforcement. The terminology used in this section is not intended to restrict the scope of this profile to IEEE 802.1AR deployments. Terms from are used because it conveniently distinguishes between manufacturer-provisioned and operational credentials, which is important in many IoT deployments. 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.
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 intended for device identity and initial onboarding or bootstrapping protocols, such as the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol or LwM2M Bootstrap . The use of IDevIDs is intentionally limited to such onboarding scenarios even though they often have a long lifetime, or do not expire at all. There are, however, multiple onboarding and bootstrapping approaches in use. Some of them use TLS and therefore use the IDevID for client authentication, while others, such as FIDO Device Onboarding (FDO) , do not use TLS/DTLS for client authentication. In many cases, the IDevID profile and content are defined by those specifications. For these reasons, this specification focuses on the description of operational certificates such as 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, which is broader and mandates hardware, security, and process requirements outside the constraints of many IoT deployments. This profile borrows terminology and selected certificate fields from IEEE 802.1AR but intentionally omits those broader requirements.
All Certificates This section outlines the requirements for X.509 certificates that apply to all PKI entities. These requirements apply to certificates issued within the IoT device PKI (i.e., root, subordinate and end entity certificates used to authenticate IoT devices), rather than to public WebPKI server certificates. The section focuses on X.509 v3 certificates.
Version Certificates MUST be of type X.509 v3.
Serial Number 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). limits this field to a maximum of 20 octets. To reduce the risk of predictable serial numbers, CAs SHOULD generate serial numbers containing at least eight (8) octets of unpredictable output from a cryptographically secure pseudo-random number generator. The random value MAY be combined with a counter or other information that ensures uniqueness.
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. For certificates expected to be validated by constrained IoT devices, CAs SHOULD select signature algorithms supported by those devices to ensure successful validation (e.g., ECDSA P-256). Different certificates in the same chain MAY use different signature algorithms when the relying devices support validation of the resulting chain.
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. Constrained devices often lack precise UTC time; implementations SHOULD treat time checks with coarse granularity (e.g., day- or hour-level) and ignore leap seconds when validating notAfter. For devices without a reliable source of time this document recommends the use of a device management solution, which typically includes a certificate management protocol, to manage certificates used by the device over their lifecycle. 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. In many IoT deployments, IDevIDs are provisioned with an unlimited lifetime, as described in . This helps prevent devices from being accidentally bricked due to certificate expiration. A real-world example occurred in 2018, when Oculus Rift headsets became unusable after an Oculus certificate expired . Oculus later issued a manual patch, as the expired certificate also blocked the standard software update path. For this purpose, the special GeneralizedTime value 99991231235959Z is used in the notAfter field, as described in . However, the CA certificate and subordinate CA certificates in the certification path may still have finite validity periods. Careful consideration is therefore required before issuing IDevID certificates with no maximum validity period, since an effectively unlimited certificate lifetime is only useful if the relevant certification path remains usable for the intended lifetime of the device. Deployments also need to verify that their CA software and issuance policy support the intended validity model. Some CA implementations and policies do not permit subordinate CA certificates or end-entity certificates to outlive the issuing CA certificate. 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 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 . Consistent with and , 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, the time portion of notAfter is 03:42:00.
 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 support one of the following algorithms:
  • id-ecPublicKey with secp256r1,
  • id-ecPublicKey with secp384r1, and
  • id-ecPublicKey with secp521r1.
TLS 1.3 certificate-based authentication requires end-entity certificates containing public keys suitable for digital signatures. TLS 1.2 also defined static DH/ECDH certificate-based key exchange modes in which the end-entity certificate contains a key-agreement public key rather than a signature public key. This specification prohibits the use of such static DH/ECDH end-entity certificates with TLS 1.2. There is no requirement for CA certificates to use the same algorithm as the end entity certificate. Certificates with longer lifetime may well use a cryptographically stronger algorithm. However, CAs (or their administrators) that issue certificates intended to be validated by constrained IoT devices SHOULD select algorithms supported by those devices to ensure successful validation. Longer-lived CA certificates MAY intentionally use stronger or different algorithms if the target devices are expected to validate such chains successfully.
Certificate Revocation Checks Constrained IoT devices often lack the resources to perform traditional Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) checks. Consistent with the guidance in , neither OCSP nor CRLs are used by constrained IoT devices during the TLS handshake. Instead, IoT deployments generally rely on short-lived operational end-entity certificates, such as LDevID certificates, managed via automated onboarding and management protocols (such as Lightweight Machine-to-Machine ). Because these protocols can distribute and update certificates on demand, they make real-time revocation checks largely unnecessary. Since these checks are bypassed, the CRL Distribution Points extension and the Authority Information Access (AIA) extension for OCSP SHOULD NOT be included in IoT device certificates. If they are present, they MUST NOT be marked critical. However, the AIA extension MAY be used to provide the caIssuer access method, enabling peers with sufficient resources to fetch certificate chains. When designing the application layer, developers must account for the fact that updating a certificate does not automatically affect existing, long-lived TLS sessions. TLS alone does not mandate continuous validity checks once a connection is established. Furthermore, TLS 1.3 natively supports only client-to-server post-handshake authentication. Achieving mutual post-handshake authentication requires Exported Authenticators , which requires the application-layer protocol to carry the authentication payload. Therefore, if continuous validation is strictly required for a long-lived connection, it is the application's responsibility to enforce this policy by actively triggering re-authentication or tearing down and re-establishing the TLS session. Ultimately, instead of attempting to perform revocation checks directly on the constrained device, it is RECOMMENDED to delegate this responsibility to the IoT device operator, who can take the necessary administrative actions (such as deploying updated certificates) to keep the network secure and operational. While the above recommendation is valid in most cases, it should be considered carefully on a case-by-case basis, taking into account the security risks associated with not re-authenticating peers and the cost/complexity of implementing an application-layer solution.
Root CA Certificate This section outlines the requirements for root CA certificates.
Subject requires that, when the subject is a CA, the subject field be populated with a non-empty distinguished name. Therefore, Root CA certificates MUST have a non-empty subject field. This is because a CA's Subject DN becomes the subordinate certificate's Issuer DN, which MUST NOT be empty. The subject field MUST contain the commonName, the organizationName, and the countryName attribute and MAY contain an organizationalUnitName attribute. If a subjectAltName extension is present, it SHOULD be set to a value consistent with the subject and SHOULD NOT be marked critical.
Authority Key Identifier 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 SHOULD be set to aid path construction. 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 SHOULD be set in Root CA certificates. If present, it MUST be marked critical and MUST include keyCertSign. If the CA signs CRLs, cRLSign MUST also be set. The digitalSignature bit is only needed when the same CA key is used to sign objects other than certificates or CRLs, such as OCSP responses. The extension MAY be omitted only in closed deployments where all relying parties are configured to accept the Root CA certificate as a trust anchor according to local policy without processing the Key Usage extension.
Extended Key Usage 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. Omitting pathLenConstraint follows common root CA practice but is not meant to encourage arbitrarily deep certification hierarchies in IoT deployments. Shallow hierarchies remain preferable for constrained devices.
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 defines the key usage extension. The Key Usage extension MUST be set, MUST be marked critical, and the keyCertSign purpose MUST be set. If the subordinate CA issues CRLs, the cRLSign purpose MUST also be set. 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 (AIA) 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 certificates 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. This specification removes the requirement in that stipulated the exclusive use of EUI-64 in the subject field of end entity certificates. 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. It is common to use serial numbers as identifiers for IoT devices, but the term "serial number" is overloaded. This profile distinguishes between a manufacturer-assigned device serial number and a link-layer identifier such as an EUI-48, EUI-64, or MAC address. A manufacturer-assigned device serial number is an identifier assigned to a device by its manufacturer. When this identifier is included in the certificate subject distinguished name (Subject DN), provides the X520SerialNumber attribute: This value is part of the Subject DN. Section 8.6 of mandates that the Subject DN is not null and encourages use of the X520SerialNumber attribute as the primary name for the device. An EUI-48 or EUI-64 identifies a link-layer interface or, depending on the allocation scheme, a device. It has defined binary semantics and is not inherently the same concept as a manufacturer's product serial number. A deployment may use an EUI-64 as its device serial number, but that does not make the concepts identical. A device serial number can be an arbitrary manufacturer-defined string, while a device can have multiple MAC addresses, and those addresses can change when interfaces are replaced or reconfigured. Many constrained IoT devices, however, do not have more than one network interface; for those devices it can be convenient for manufacturers to reuse an existing unique MAC address or EUI as the device identifier. requires the identifier in a client certificate to be an EUI-64 and permits that identifier to appear either in the subjectAltName or in the leftmost commonName component of the Subject DN. This profile updates that guidance by distinguishing manufacturer-assigned device serial numbers from EUI-48 and EUI-64 link-layer identifiers. uses a device serial number to identify a BRSKI pledge. Consistent with , identifies the device serial-number field as the X520SerialNumber attribute defined in . The registrar extracts this certified device serial number from the pledge's IDevID and uses it in voucher processing. The important semantic point is that BRSKI needs a stable manufacturer device identifier; does not require this value to be an EUI-48 or EUI-64. A manufacturer-assigned device serial number included in the Subject DN MUST be encoded in the X520SerialNumber attribute. If an EUI-48 or EUI-64 is used to identify a device, it SHOULD be encoded in the subjectAltName extension using the MACAddress otherName defined in . An EUI-64 that serves as the manufacturer-assigned device serial number MAY instead be encoded in the X520SerialNumber attribute. 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. The MACAddress otherName carries the value as an OCTET STRING. An EUI-48 is encoded as exactly 6 octets and an EUI-64 is encoded as exactly 8 octets. also defines how this name form is used with the Name Constraints extension, allowing a CA certificate to constrain permitted or excluded MAC address ranges, for example by an Organizationally Unique Identifier (OUI). The CA needs to validate the identifier's relationship to the subject. For a MACAddress value, requires the CA to ensure that the address is owned by, or expected to be owned by, the subject device for the certificate's lifetime. This requirement can be difficult for replaceable interfaces, virtual interfaces, locally administered addresses, and MAC address randomization. Both manufacturer-assigned device serial numbers and EUI-48 or EUI-64 values can expose stable identifiers to certificate recipients. TLS 1.3 better protects client certificates against passive observers than earlier TLS versions because the client certificate is encrypted and sent only after the server certificate has been received and validated. The authenticated peer, however, still learns the identifier. An EUI-48 or EUI-64 can reveal organizational allocation information and can enable correlation across networks or application contexts. A stable device serial number has similar correlation risks. Environments that are concerned about such traffic analysis SHOULD avoid using stable, globally identifiable device identifiers in operational certificates. This can be achieved, for example, by using an enrollment protocol to migrate from identifiable IDevID certificates to less identifiable operational LDevID certificates, or by provisioning operational certificates that contain only deployment-local or otherwise non-public identifiers. 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.
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 digitalSignature key usage purpose MUST be specified. Other key usages are set according to the intended usage of the key. 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. The selected EKUs MUST match the intended TLS role of the device or service using the certificate.
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. Trust-anchor lifecycle management is central to IoT certificate profiles. IoT devices, especially in industrial deployments, often remain in service for many years and may operate in environments where physical access is expensive or impossible. A certificate profile that assumes static trust anchors for the entire device lifetime makes algorithm transitions, CA rollover, manufacturer changes, and incident response significantly harder. 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 certificate-based authentication, 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 using the secp256r1 curve with mutual authentication, around 40% of the entire handshake payload is consumed by the two exchanged certificates. Deployments should first apply the certificate-profile recommendations in this document, since they reduce both bandwidth use and certificate processing cost without requiring additional TLS extensions:
  • Use elliptic curve cryptography (ECC) instead of RSA-based certificates. 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).
  • Include only the certificate fields and extensions needed for the intended deployment. The profile in identifies certificate content that can be omitted in constrained IoT deployments.
  • Transmit only the certificates needed by the peer to build a path to one of its configured trust anchors. Trust anchors are intended to be provisioned out of band and a trust anchor received in a TLS Certificate message cannot be assumed trustworthy. A trust anchor therefore SHOULD NOT be included in the Certificate message.
TLS and DTLS also provide mechanisms that reduce how often large certificate chains have to be exchanged. Session resumption reduces the size of subsequent handshakes after an initial authenticated exchange. DTLS Connection IDs , when applicable, help preserve long-lived associations across address or path changes and can therefore avoid handshakes that would otherwise be needed to re-establish the connection. Omitting trust anchors from the Certificate message is the preferred baseline, but the sender still has to provide enough information for the peer to validate the presented end entity certificate. In some deployments the sender cannot infer which trust anchor the peer has configured. For example, the peer's trust anchor might be an intermediate CA rather than a root CA, or a root key transition might mean that different devices have different old or new trust anchors installed. In these cases, the peer MAY use the "certificate_authorities" extension to indicate the CAs which an endpoint supports, see , to help the sender select an appropriate certificate chain. During trust-anchor updates, deployments may also need transitional cross-certificates, such as the newWithOld and oldWithNew certificates described by . Such certificates can help bridge the transition, but they do not replace out-of-band provisioning of trust anchors. Additional techniques are available, but they are more deployment-specific and are not uniformly supported by TLS/DTLS stacks:
  • Certificate compression can reduce the size of certificates that still have to be transmitted. Related guidance for IoT deployments is provided by .
  • Server certificate caching can reduce retransmission when a client repeatedly connects to the same server, which is a common IoT deployment scenario. The TLS cached info extension defines such a mechanism. was written for TLS/DTLS 1.2 and describes the server response in ServerHello. In TLS 1.3, the client offers cached_info in ClientHello and the server confirmation is carried in EncryptedExtensions (). defines cached information types for server Certificate messages and server CertificateRequest messages. It does not define caching of client Certificate messages. For TLS 1.3, the server Certificate message includes a certificate_request_context field. For server authentication, this field is zero length (), so it does not by itself prevent server certificate information from being cached. The CertificateRequest message also includes a certificate_request_context field. For client authentication in the main handshake, this field is zero length unless post-handshake authentication is used (). Consequently, caching CertificateRequest messages can still be applicable when the server's client-authentication request parameters are large and stable. The potentially large parts are the extensions in CertificateRequest, especially the certificate_authorities extension, which lists distinguished names of acceptable CAs (). In many IoT deployments, unlike WebPKI-style deployments, this list is small or omitted because only a small number of trust anchors is used. In contrast, CertificateRequest caching is not useful for post-handshake authentication since the certificate_request_context changes between requests.
  • The client certificate URL mechanism defined in can replace client certificates in the handshake with references to external certificate objects. When applications perform TLS client authentication via DNS-Based Authentication of Named Entities (DANE) TLSA records, then the DANE Client Identity TLS extension may be used to reduce the packets on the wire. The term "TLSA" does not stand for anything; it is the name of the RRtype, as explained in .
  • Alternative certificate formats, such as raw public keys or CBOR-encoded certificates , can reduce credential size where the application and provisioning model support them.
  • Certificate handles, where available, are another form of caching.
These additional mechanisms can be useful, but they can also introduce side effects, such as reliance on DNS or directory infrastructure, cache invalidation requirements, privacy exposure to retrieval services, changes to the credential provisioning model, and additional implementation code. A deployment SHOULD first prefer mechanisms with broad TLS/DTLS 1.3 support and low operational complexity: compact certificate profiles, shallow certification paths, omitting trust anchors from the handshake, session resumption, DTLS Connection IDs, and certificate compression. More deployment-specific mechanisms such as cached certificate information, certificate URLs, DANE client identity, or certificate handles SHOULD be used only when their operational dependencies, cache invalidation behavior, and privacy impact are acceptable for the deployment.
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_SHA256
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. TLS 1.3 enforces deterministic nonce generation for all AEAD cipher suites. However, this is not the case for TLS 1.2. Therefore, when using the GCM-based cipher suite with TLS 1.2, the recommendations in relating 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 Requirement
TLS_AES_128_CCM_8_SHA256 MUST implement for compatibility with and deployments; not recommended for new deployments
TLS_AES_128_CCM_SHA256 SHOULD implement
TLS_AES_128_GCM_SHA256 SHOULD implement
Post-Quantum Cryptography (PQC) Considerations The recommendations and ciphersuites in this profile are based on classical cryptography and are not quantum-resistant. Guidance for using post-quantum cryptography with application protocols, including TLS, is provided by . That document is the primary source of PQC deployment recommendations for applications and constrained environments. It discusses algorithm selection, migration planning, and the operational impact of larger key shares, public keys, signatures, and certificates. PQC transition planning is especially relevant for IoT devices because product lifetimes are long and device constraints limit the adoption of larger key sizes and more complex cryptographic operations . Deployments also need to evaluate the energy impact of PQC choices . Additional background for engineers is provided by , and guidance on PQC use with constrained hardware security modules is provided by . As a transitional measure, allows certificate-based authentication to be combined with a strong external PSK that is incorporated into the TLS 1.3 key schedule. This provides confidentiality protection against a future cryptographically relevant quantum computer, provided that the external PSK is generated and distributed securely. It does not make the certificate-based authentication quantum resistant. Deployments can use this mechanism as a migration path while PQC algorithms for certificate-based authentication are being introduced.
Privacy Considerations The privacy considerations in largely continue to apply. However, compared to TLS 1.2 and DTLS 1.2, TLS 1.3 and DTLS 1.3 encrypt a larger portion of the handshake, which reduces the amount of identity and credential metadata observable on the wire by passive attackers. Extensions, such as the encrypted ClientHello, further increase privacy protection. Certificate fields can expose stable device identifiers and other metadata. In particular, IDevIDs and LDevIDs may reveal manufacturer identity, device serial numbers, or other information to peers. Protection against passive observers is, however, substantially improved since certificates are encrypted in TLS 1.3 and DTLS 1.3. Client certificates are also sent only after the server certificate has been received and validated. The server still receives the certificate and learns the identifiers it contains. Manufacturer-assigned device serial numbers and EUI-48 or EUI-64 values can enable correlation across networks or application contexts. EUI-48 and EUI-64 values can also reveal organizational allocation information. Deployments that are concerned about such traffic analysis SHOULD use an enrollment protocol to migrate from identifiable IDevID certificates to less identifiable operational LDevID certificates. Deployments that continue to use stable identifiers in certificates expose those identifiers to peers and can enable correlation across connections, networks, or application contexts. Some deployments use the mechanisms discussed in the Certificate Overhead section, such as certificate URLs or external certificate retrieval, instead of always transmitting full certificates in the handshake. In these cases, the privacy properties differ because stable identifiers may be exposed to retrieval services, directories, or to observers of those retrieval transactions. Where privacy is a deployment requirement, implementations and PKI profiles should include only the minimum identity information needed for authorization and interoperability. When Connection IDs are used with DTLS 1.3, CID negotiation in post-handshake messages is encrypted and integrity protected. In addition, record sequence numbers are encrypted. Compared to DTLS 1.2 CID, this makes tracking by on-path adversaries more difficult and improves privacy in multi-home and mobile deployments ().
Security Considerations This entire document is about security.
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. It is therefore recommended to introduce randomness into the signature scheme, as in the original ECDSA specification, or to combine deterministic and randomized techniques, for example as described in . However, the use of randomized signature algorithms can make implementations more difficult to test, as discussed in .
Authentication- and Integrity-Only Cipher Suites defines TLS 1.3 cipher suites that provide authentication and message integrity without confidentiality. limits their applicability to cases where confidentiality and privacy requirements are absent or explicitly relaxed, but authenticity and integrity are still required; examples include industrial automation commands, fine-grained time updates, alarms, railway control, and safety-related recording or inspection. These cipher suites are not general-purpose TLS cipher suites. Deployments need an application-specific safety, security, and privacy analysis and need to verify that the application protocol and application data do not rely on confidentiality. This document leaves such profiling to (industrial) IoT deployments and therefore does not specify authentication- or integrity-only cipher suites.
IANA Considerations This document makes no requests to IANA.
References Normative References The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 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. The Transport Layer Security (TLS) Protocol Version 1.3 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK] Media Access Control (MAC) Addresses in X.509 Certificates Vigil Security, LLC DigiCert, Inc. AKAYLA, Inc. Penguin Securities Pte. Ltd. NthPermutation Security LLC This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a layer-2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE). Terminology for Constrained-Node Networks 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 research and standardization work for constrained-node networks. This document obsoletes RFC 7228. Transport Layer Security (TLS) Extensions: Extension Definitions 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] Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 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] Importing External Pre-Shared Keys (PSKs) for TLS 1.3 This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things 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. Return Routability Check for DTLS 1.2 and 1.3 This document specifies a Return Routability Check (RRC) subprotocol for use in the 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 RFCs 9146 and 9147 are encouraged to also provide the RRC functionality described in this document. For this reason, this document updates RFCs 9146 and 9147. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 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. Record Size Limit Extension for TLS 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. Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA 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] Elliptic Curve Cryptography Subject Public Key Information 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] Service Identity in TLS 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 Connection Identifier for DTLS 1.2 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. Terminology for Constrained-Node Networks 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. Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP) 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 interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. Randomness Improvements for Security Protocols Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable "cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Lightweight Certificate Management Protocol (CMP) Profile 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. IoT DNS Security and Privacy Guidelines Inria UCL UCL Infoblox INSA-Lyon & Inria This document outlines guidance for Internet of Things (IoT) manufacturers regarding the implementation of DNS stub resolver software on devices, and for the management zones used for purposes such as device configuration and software upgrades. It aims to mitigate security threats, enhance privacy, and to address operational security challenges. DNS resolution between devices and management zone servers depends upon DNS services within operator networks, and these services and operator networks can be impacted by device behavior. Hence this document also provides guidance to network operators that deploy IoT devices to mitigate the specific risks identified in this document and take advantage of improved DNS security mechanisms provided by manufacturers. Post-Quantum Cryptography for Engineers 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), and it details 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. TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC. A Password Authenticated Key Exchange Extension for TLS 1.3 Apple, Inc. Google LLC Apple, Inc. Apple, Inc. The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. Extended Key Update for Transport Layer Security (TLS) 1.3 Siemens Münster Univ. of Applied Sciences Nokia Siemens Zscaler TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. Energy Consumption Evaluation of Post-Quantum TLS 1.3 for Resource-Constrained Embedded Devices 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 Performance Evaluation of Post-Quantum TLS 1.3 on Resource-Constrained Embedded Systems Springer International Publishing Transitioning the Use of Cryptographic Algorithms and Key Lengths The Constrained Application Protocol (CoAP) 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. ISO/IEC/IEEE International Standard for Telecommunications and exchange between information technology systems--Requirements for local and metropolitan area networks--Part 1AR:Secure device identity IEEE FIDO Device Onboard Specification 1.1 FIDO Alliance Lightweight Machine to Machine (LwM2M) V.1.2.2 Technical Specification: Transport Bindings OMA SpecWorks Lightweight Machine to Machine (LwM2M) V.1.2.2 Technical Specification: Core OMA SpecWorks How To Patch Your Oculus Rift Differential Attacks on Deterministic Signatures Transport Layer Security (TLS) Renegotiation Indication Extension 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] Exported Authenticators in TLS 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. Secondary Certificate Authentication of HTTP Servers 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 EAP-TLS Authentication Protocol 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] EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 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. Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) 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] Guidance for External Pre-Shared Key (PSK) Usage in TLS This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. TLS Encrypted Client Hello This document describes a mechanism in Transport Layer Security (TLS) for encrypting a message under a server public key. Bootstrapping Remote Secure Key Infrastructure (BRSKI) 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. Enrollment over Secure Transport 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. Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) 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. Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages 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] A Firmware Update Architecture for Internet of Things 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. A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors 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. // This document is a product of the Internet Research Task Force // (IRTF). The IRTF publishes the results of Internet-related // research and development activities. These results might not be // suitable for deployment. TLS Certificate Compression 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. Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available. Transport Layer Security (TLS) Cached Information Extension 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. TLS Client Authentication via DANE TLSA records Salesforce OpenSSL Corporation The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server. The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA 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] CBOR Encoded X.509 Certificates (C509 Certificates) Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO 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 common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. Usage Limits on AEAD Algorithms 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. Post-Quantum Cryptography Recommendations for TLS-based Applications Nokia University of the Bundeswehr Munich Post-quantum cryptography presents new challenges for device manufacturers, application developers, and service providers. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and supporting protocols such as DNS. Adapting Constrained Devices for Post-Quantum Cryptography Nokia Citrix UK National Cyber Security Centre PQShield This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) 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. Edwards-Curve Digital Signature Algorithm (EdDSA) 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. Hedged ECDSA and EdDSA Signatures 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. TLS 1.3 Authentication and Integrity-Only Cipher Suites 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.
Acknowledgments We would like to thank Henk Birkholz, Hendrik Brockhaus, Roman Danyliw, Menachem Dodge, Martin Duke, Gorry Fairhurst, Miek Gieben, Russ Housley, Ben Kaduk, Achim Kraus, John Mattsson, Tiru Reddy, Scott Rose, Rich Salz, Mohit Sethi, Ketan Talaulikar, Martin Thomson, Marco Tiloca, and Éric Vyncke. Finally, we would like to thank our security area director Deb Cooley for her detailed review comments.
Contributors