TLS/DTLS 1.3 Profiles for the Internet of Things

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document defines a profile of DTLS 1.3 [DTLS13] and TLS 1.3 [RFC8446] that offers communication security services for IoT applications and is reasonably implementable on many constrained devices. Profile thereby means that available configuration options and protocol extensions are utilized to best support the IoT environment.¶

For IoT profiles using TLS/DTLS 1.2 please consult [RFC7925]. This document re-uses the communication pattern defined in [RFC7925] and makes IoT-domain specific recommendations for version 1.3 (where necessary).¶

TLS 1.3 has been re-designed and several previously defined extensions are not applicable to the new version of TLS/DTLS anymore. The following features changed with the transition from TLS 1.2 to 1.3:¶

• TLS 1.3 introduced the concept of post-handshake authentication messages, which partially replaced the need for the re-negotiation feature [RFC5746] available in earlier TLS versions. However, rekeying defined in Section 4.6.3 of [TLS13] does not provide forward secrecy and post-handshake authentication defined in Section 4.6.2 of [TLS13] only offers client-to-server authentication. The "Exported Authenticator" specification, see [RFC9261], recently added support for mutual, post-handshake authentication but requires payloads to be exchanged by the application layer protocol.¶
• Rekeying of the application traffic secret does not lead to an update of the exporter secret (see Section 7.5 of [TLS13]) 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 [RFC5216], does not exist in TLS 1.3. As a consequence, EAP-TLS 1.3 [RFC9190] introduced a dummy message.¶
• [RFC4279] introduced PSK-based authentication to TLS, a feature re-designed in TLS 1.3. The "PSK identity hint" defined in [RFC4279], which is used by the server to help the client in selecting which PSK identity to use, is, however, not available anymore in TLS 1.3.¶

Finally, ciphersuites were depreciated and the RSA-based key transport is not yet supported in TLS 1.3.¶

2. Credential Types

In accordance with the recommendations in [RFC7925], a compliant implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD implement TLS_CHACHA20_POLY1305_SHA256.¶

Pre-shared key based authentication is integrated into the main TLS/DTLS 1.3 specification and has been harmonized with session resumption.¶

A compliant 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.¶

A plain PSK-based TLS/DTLS client or server MUST implement the following extensions:¶

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

For use of external pre-shared keys [RFC9258] makes the following recommendation:¶

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

Where possible, the importer interface defined in [RFC9258] MUST be used for external PSKs. This ensures that external PSKs used in (D)TLS 1.3 are bound to a specific key derivation function (KDF) and hash function.¶

The SNI extension is discussed in this document and the justification for implementing and using the ALPN extension can be found in [RFC9325].¶

For TLS/DTLS clients and servers implementing raw public keys and/or certificates the guidance for mandatory-to-implement extensions described in Section 9.2 of [RFC8446] MUST be followed.¶

3. Error Handling

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

4. Session Resumption

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

5. Compression

TLS 1.3 does not have support for compression of application data traffic, as offered by previous versions of TLS. Applications are therefore responsible for transmitting payloads that are either compressed or use a more efficient encoding otherwise.¶

With regards to the handshake itself, various strategies have been applied to reduce the size of the exchanged payloads. TLS and DTLS 1.3 use less overhead, depending on the type of key confirmations, when compared to previous versions of the protocol. Additionally, the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken compression of the handshake a step further by utilizing out-of-band knowledge between the communication parties to reduce the amount of data to be transmitted at each individual handshake, among applying other techniques.¶

6. Perfect Forward Secrecy

TLS 1.3 allows the use of PFS with all ciphersuites since the support for it is negotiated independently.¶

7. Keep-Alive

The discussion in Section 10 of [RFC7925] is applicable.¶

8. 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 Section 11 of [RFC7925].¶

In general, the recommendations in Section 7.3 of [DTLS13] regarding ACKs apply. In particular, "[w]hen DTLS 1.3 is used in deployments with lossy networks, such as low-power, long-range radio networks as well as low-power mesh networks, the use of ACKs is recommended" to signal any sign of disruption or lack of progress. This allows for selective or early retransmission, which leads to more efficient use of bandwidth and memory resources.¶

Due to the vast range of network technologies used in IoT deployments, from wired LAN to GSM-SMS, it's not possible to provide a universal recommendation for an initial timeout. Therefore, it is RECOMMENDED that DTLS 1.3 implementations allow developers to explicitly set the initial timer value. Developers SHOULD set the initial timeout to be twice the expected round-trip time (RTT), but no less than 1000ms. For specific application/network combinations, a sub-second initial timeout MAY be set. In cases where no RTT estimates are available, a 1000ms initial timeout is suitable for the general Internet.¶

For RRC, the recommendations in Section 7.5 of [I-D.ietf-tls-dtls-rrc] 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.¶

9. Random Number Generation

The discussion in Section 12 of [RFC7925] is applicable with one exception: the ClientHello and the ServerHello messages in TLS 1.3 do not contain gmt_unix_time component anymore.¶

10. Server Name Indication

This specification mandates the implementation of the Server Name Indication (SNI) extension. Where privacy requirements require it, the ECH (Encrypted Client Hello) extension [I-D.ietf-tls-esni] prevents an on-path attacker to determine the domain name the client is trying to connect to.¶

Since the Encrypted Client Hello extension requires use of Hybrid Public Key Encryption (HPKE) [I-D.irtf-cfrg-hpke] and additional protocols require further protocol exchanges and cryptographic operations, there is a certain overhead associated with this privacy feature.¶

Note that in industrial IoT deployments the use of ECH may not be an option because network administrators inspect DNS traffic generated by IoT devices in order to detect malicious behaviour.¶

Besides, to avoid leaking DNS lookups from network inspection altogether further protocols are needed, including DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094]. For use of such techniques in managed networks, the reader is advised to keep up to date with the protocols defined by the Adaptive DNS Discovery (add) working group [ADD].¶

11. Maximum Fragment Length Negotiation

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

12. Crypto Agility

The recommendations in Section 19 of [RFC7925] are applicable.¶

13. Key Length Recommendations

The recommendations in Section 20 of [RFC7925] are applicable.¶

14. 0-RTT Data

Appendix E.5 of [TLS13] establishes that:¶

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

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

15. Certificate Profile

This section contains updates and clarifications to the certificate profile defined in [RFC7925]. The content of Table 1 of [RFC7925] has been split by certificate "type" in order to clarify exactly what requirements and recommendations apply to which entity in the PKI hierarchy.¶

The content is also better aligned with the IEEE 802.1AR [_8021AR] specification, which introduces the terms Initial Device Identifier (IDevID) and Locally Significant Device Identifiers (LDevIDs). IDevIDs and LDevIDs are Device Identifier (DevID) and a DevID consists of¶

• a private key,¶
• a certificate (containing the public key and the identifier certified by the certificate's issuer), and¶
• a certificate chain up to a trust anchor. The trust anchor is is usually the root certificate).¶

The IDevID is typically provisioned by a manufacturer and signed by the manufacturer CA. It is then used to obtain operational certificates, the LDevIDs, from the operator or owner of the device. Some protocols also introduce an additional hierarchy with application instance certificates, which are obtained for use with specific applications.¶

IDevIDs are primarily used with device onboarding or bootstrapping protocols, such as the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol [RFC8995] or by LwM2M Bootstrap [LwM2M]. Hence, the use of IDevIDs is limited in purpose even though they have a long lifetime, or do not expire at all. While some bootstrapping protocols use TLS (and therefore make use of the IDevID as part of client authentication) there are other bootstrapping protocols that do not use TLS/DTLS for client authentication, such as FIDO Device Onboarding (FDO) [FDO]. In many cases, a profile for the certificate content is provided by those specifications. For these reasons, this specification focuses on the description of LDevIDs.¶

While the IEEE 802.1AR terminology is utilized in this document, this specification does not claim conformance to IEEE 802.1AR since such a compliance statement goes beyond the use of the terminology and the certificate content and would include the use of management protocols, fulfillment of certain hardware security requirements, and interfaces to access these hardware security modules. Placing these requirements on network equipment like routers may be appropriate but designers of constrained IoT devices have opted for different protocols and hardware security choices.¶

16. Certificate Overhead

In a public key-based key exchange, certificates and public keys are a major contributor to the size of the overall handshake. For example, in a regular TLS 1.3 handshake with minimal ECC certificates and no subordinate CA utilizing the secp256r1 curve with mutual authentication, around 40% of the entire handshake payload is consumed by the two exchanged certificates.¶

Hence, it is not surprising that there is a strong desire to reduce the size of certificates and certificate chains. This has lead to various standardization efforts. Below is a brief summary of what options an implementer has to reduce the bandwidth requirements of a public key-based key exchange. Note that many of the standardized extensions are not readily available in TLS/DTLS stacks since optimizations typically get implemented last.¶

• Use elliptic curve cryptography (ECC) instead of RSA-based certificate due to the smaller certificate size. This document recommends the use of elliptic curve cryptography only.¶
• Avoid deep and complex CA hierarchies to reduce the number of subordinate CA certificates that need to be transmitted and processed. See [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] for a discussion about CA hierarchies.¶
• Pay attention to the amount of information conveyed inside certificates.¶
• Use session resumption to reduce the number of times a full handshake is needed. Use Connection IDs [RFC9146], when possible, to enable long-lasting connections.¶
• Use the TLS cached info [RFC7924] extension to avoid sending certificates with every full handshake.¶
• Use client certificate URLs [RFC6066] instead of full certificates for clients. When applications perform TLS client authentication via DNS-Based Authentication of Named Entities (DANE) TLSA records then the [I-D.ietf-dance-tls-clientid] specification may be used to reduce the packets on the wire. Note: The term "TLSA" does not stand for anything; it is just the name of the RRtype, as explained in [RFC6698].¶
• Use certificate compression as defined in [RFC8879].¶
• Use alternative certificate formats, where possible, such as raw public keys [RFC7250] or CBOR-encoded certificates [I-D.ietf-cose-cbor-encoded-cert].¶

The use of certificate handles, as introduced in cTLS [I-D.ietf-tls-ctls], is a form of caching or compressing certificates as well.¶

Whether to utilize any of the above extensions or a combination of them depends on the anticipated deployment environment, the availability of code, and the constraints imposed by already deployed infrastructure (e.g., CA infrastructure, tool support).¶

17. Ciphersuites

According to Section 4.5.3 of [DTLS13], 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 5.3 and 5.4 of [I-D.irtf-cfrg-aead-limits] for further discussion on this topic, as well as references to the analysis supporting these conclusions.¶

Specifically, [DTLS13] 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 [RFC7925] and [CoAP] 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, this document RECOMMENDS that implementations support the following two ciphersuites:¶

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256¶
• TLS_ECDHE_ECDSA_WITH_AES_128_CCM¶

and offer them as their first choice. These ciphersuites provide confidentiality and integrity limits that are considered acceptable in the most general settings. For the details on the exact bounds of both ciphersuites see Section 4.5.3 of [DTLS13]. Note that the GCM-based ciphersuite offers superior interoperability with cloud services at the cost of a slight increase in the wire and peak RAM footprints.¶

When the GCM-based ciphersuite is used with TLS 1.2, the recommendations in Section 7.2.1 of [RFC9325] related to deterministic nonce generation apply. In addition, the integrity limits on key usage detailed in Section 4.4 of [RFC9325] also apply.¶

Table 1 summarizes the recommendations regarding ciphersuites:¶

18. Fault Attacks on Deterministic Signature Schemes

A number of passive side-channel attacks as well as active fault-injection attacks (e.g., [Ambrose2017]) 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., [RFC6979] ECDSA or EdDSA [RFC8032]) is used.¶

Most of these attacks assume physical access to the device and are therefore especially relevant to smart cards as well as IoT deployments with poor or non-existent physical security.¶

In this security model, it is recommended to combine both randomness and determinism, for example, as described in [I-D.irtf-cfrg-det-sigs-with-noise].¶

19. Open Issues

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

20. Security Considerations

This entire document is about security.¶

21. IANA Considerations

This document makes no requests to IANA.¶

Acknowledgments

We would like to thank Ben Kaduk, Hendrik Brockhaus, and John Mattsson.¶

Contributors

Authors' Addresses