Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
Extracted elements (30)
All certificates in this profile (end-entity and CA) are signed using ECDSA exclusively, rather than supporting RSA, DSA, and ECDSA. This reduces the amount of flash memory needed on an IoT device because fewer algorithm implementations must be stored.
Certificate revocation via OCSP or CRLs is not used in this profile; instead, revocation relies on a software update mechanism. This avoids the overhead of additional protocol handshakes on constrained devices, though it limits granularity of revocation.
The 9-second initial retransmission timeout was chosen over the RFC 6347-recommended 1 second because IoT networks (e.g., IEEE 802.15.4, GSM-SMS) have high latency variance and low bandwidth. It achieves the same worst-case wait time (63 seconds) as a 1-second timeout but triggers fewer than half the retransmissions (2 vs. 5), reducing congestion.
The PSK ciphersuite (TLS_PSK_WITH_AES_128_CCM_8) does not offer perfect forward secrecy because it does not use a DH exchange. This is an explicit trade-off: the PSK ciphersuite offers excellent performance, very small memory footprint, and lowest on-wire overhead, making it suitable for the most constrained IoT devices.
TLS/DTLS-level compression is disabled following RFC 7525 guidance due to the CRIME attack. For IoT applications, application-layer protocols are already highly optimized, and compression at the DTLS layer only increases code size and complexity without meaningful benefit.
Named finite-field DH groups (FFDHE-TLS) are not applicable to this profile since it relies exclusively on ECC-based key exchange (ECDHE). The recommended curve at time of writing is secp256r1 with uncompressed points, following CoAP recommendations.
The SNI extension cannot be used with constrained servers that are not provisioned with DNS domain names (e.g., local IoT devices identified by EUI-64), because SNI does not offer the ability to convey a 64-bit EUI-64 identifier.
TLS 1.3 is noted as being developed at the time of writing, but the profile defined in this document is not expected to 'just work' with TLS 1.3 due to significant changes in that version. This profile is explicitly scoped to TLS/DTLS 1.2.
A device compliant with the certificate-based profile MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow all guidance in Section 4.4. Support for the 'cached_info' extension (RFC 7924) is REQUIRED to reduce handshake overhead from repeated certificate transmission.
A device compliant with the PSK profile MUST implement TLS_PSK_WITH_AES_128_CCM_8 and follow all guidance in Section 4.2. This ciphersuite uses AES-128 in CCM mode with an 8-octet authentication tag and HMAC-SHA-256 as the PRF.
A device compliant with the raw public key profile MUST implement TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and follow all guidance in Section 4.3. This ciphersuite uses ECDHE for key establishment and ECDSA for authentication, providing perfect forward secrecy.
An initial DTLS retransmission timer value of 9 seconds with exponential back-off up to no less than 60 seconds is RECOMMENDED. This is chosen to absorb large latency variance from constrained endpoints or network characteristics such as GSM-SMS, while minimizing spurious retransmissions.
Constrained clients MUST implement session resumption to reduce message exchanges, computational overhead, and bandwidth. When the server is constrained, the client MUST implement RFC 5077 (stateless ticket-based resumption) to avoid requiring per-session state on the server.
Error messages marked as RESERVED (decryption_failed_RESERVED, no_certificate_RESERVED, export_restriction_RESERVED) MUST NOT be used with this profile. The TLS server MUST return decrypt_error instead of unknown_psk_identity for PSK ciphersuites.
For client certificates, the identifier used in the SubjectAltName or in the leftmost CN component of subject name MUST be an EUI-64. This applies to all client-side certificate deployments under this profile.
Implementations SHOULD NOT reuse ephemeral DH keys over multiple protocol exchanges. Reuse of ephemeral keys partially defeats perfect forward secrecy and increases the damage extent of a long-term key compromise.
IoT devices MUST provide support for a server certificate chain of at least 3 (not including the trust anchor) and MAY reject connections from servers offering chains longer than 3. IoT devices MAY have client certificate chains of any length.
It MUST be ensured that a different key pair is provisioned for each device and installed in as secure a manner as possible. Generating public/private keys on the IoT device itself is preferable to generating them externally.
PSK identities SHOULD NOT assume a structured format such as domain names or IP addresses, and a byte-by-byte comparison MUST be used by the server for any operation related to the PSK identity. These identifiers are called 'absolute' per RFC 6943.
Server certificates MUST NOT use DNS domain names in the CN field and must instead use the subjectAltName attribute. Certificates MUST NOT contain wildcard characters and MUST NOT contain multiple names (e.g., more than one dNSName field).
The client MUST send the 'signature_algorithms' extension to select SHA-256; if absent, RFC 5246 defaults to SHA-1/ECDSA for ECDH_ECDSA and ECDHE_ECDSA key exchange algorithms. This extension is not applicable to PSK-based ciphersuites.
TLS/DTLS clients MUST implement support for client certificate URLs (RFC 6066) for environments where client-side certificates are used and the server-side is not constrained. This extension is NOT RECOMMENDED for constrained servers due to additional workload and DoS risk.
TLS/DTLS layer compression is NOT RECOMMENDED by this profile. For server-initiated message exchange patterns, the use of the DTLS heartbeat extension (RFC 6520) is RECOMMENDED to maintain NAT and firewall state.
Section 22 addresses privacy considerations for the IoT TLS/DTLS profile. TLS/DTLS handshake metadata (such as certificate identifiers, SNI values, and PSK identities) transmitted in cleartext can reveal device identity and association patterns to observers, which is particularly sensitive for IoT deployments.
Certificate content for this profile is restricted to specific fields defined in Table 1: version (X.509 v3), serialNumber, signature (ecdsa-with-SHA256 or stronger), issuer, validity, subject, subjectPublicKeyInfo (id-ecPublicKey), signatureAlgorithm, signatureValue, subjectAltName, BasicConstraints, Key Usage, and Extended Key Usage.
Session resumption allows a client to continue with an earlier established session using a reduced handshake with only symmetric cryptography. The server may omit the cookie exchange during resumption, but clients must still be prepared for it. Clients may send an empty session_id to force a full handshake.
The DTLS cookie exchange uses a HelloVerifyRequest message containing a stateless cookie sent by the server, which must be returned in the client's subsequent ClientHello. While optional for the server to initiate, clients MUST be prepared to respond to it to resist flooding/DoS attacks.
Three credential types are defined for this IoT profile: Pre-Shared Secret (PSK), Raw Public Key (RPK), and Certificates. Each type implies different mandatory-to-implement ciphersuites, configuration preconditions, and trust anchor requirements.
IoT devices often lack sources of randomness available on desktop systems (mouse movement, keystroke timing, hard drive turbulence). Insufficient entropy can cause the same keys to be generated repeatedly. Dedicated hardware RNGs or alternative entropy sources must be used, and deriving shared secrets from low-entropy sources such as passwords or device identifiers is not secure.
Physical attacks on IoT devices create additional opportunities to compromise long-term cryptographic material. PFS ciphersuites prevent an attacker from decrypting past communications after a key compromise, but this property is undermined if ephemeral DH keys are reused across sessions.