15 TLS and DTLS for IoT

15.1.1 The One-Minute View

15.1.2 Beginner Examples

• A sensor that opens a TLS connection but accepts any certificate has encryption without authentication. It may be talking privately to an impostor.
• A device using DTLS over UDP for CoAP still has to cope with lost, reordered, and duplicated datagrams. The security layer does not make a repeated command safe on its own.
• “We use TLS” is not a claim a reviewer can accept. It does not say which peer is verified, which version and cipher suite, or where the session terminates and who sees plaintext after that.

15.1.3 Overview Knowledge Check

If you can say what TLS and DTLS protect, why the transport choice matters, and why encryption is not identity, you can stop here. Continue to Practitioner to configure and review a real deployment.

15.2.1 Walkthrough: From Transport to Accepted Connection

1. Name the transport and termination point. Decide TLS (reliable stream over TCP) or DTLS (datagrams over UDP, for example CoAP), and identify exactly which component terminates the session and sees plaintext after it.
2. Choose the authentication model. Server certificate (X.509) validation; mutual TLS with a client certificate to authenticate the device; or, for constrained devices, pre-shared keys (PSK) or raw public keys. Record how the device’s own identity is proven, not only the server’s.
3. Set the version and cipher policy. Require a modern version, restrict to AEAD cipher suites with ephemeral ECDHE for forward secrecy, and disable legacy options such as static RSA key exchange, RC4, and known CBC-padding-prone suites. Read the policy back from the deployed firmware, not just a design document.
4. Validate the peer correctly. For certificates, check the trust chain, validity period, revocation or status, and the identity (name) match. Skipping the name check breaks authentication even when encryption works. For PSK, check the identity, scope, and rotation.
5. Make failure fail closed. A failed or blocked handshake must stop protected data. It must never silently downgrade to cleartext or to a weaker version. Confirm there is no plaintext fallback path.
6. Add DTLS handling where used. Confirm the anti-replay window, the per-record sequence number, the cookie or return-routability exchange against spoofed-source denial of service, and that the application deduplicates state-changing commands.
7. Record redacted evidence and retest triggers. Keep negotiated parameters and both success and failure captures with no raw secrets, and note which changes (new trust anchor, cipher policy, certificate rotation) reopen the review.

15.2.2 The Authentication Options

15.2.3 Worked Review: A CoAP/DTLS Sensor Link

A battery sensor speaks CoAP over UDP to a field gateway using DTLS with PSK. The claim under review is: the gateway accepts commands only from enrolled sensors, and the link is private and tamper-evident.

The worked decision above makes a bounded claim about one CoAP/DTLS link. Use Figure 15.2 to verify which handshake and record events support that claim and which obligations remain open.

+

Read Figure 15.2 in protocol order. The hello exchange offers and selects policy; certificate validation binds the server name to a trusted identity; ephemeral ECDHE and HKDF establish scoped traffic secrets; Finished messages authenticate the transcript; and only then do protected application records flow. The reject path is equally important: wrong identity, stale credentials, replayed records, or unacceptable policy must stop the connection. This sequence turns the worked CoAP/DTLS example into evidence for the bounded claim stated above.

15.2.4 Practitioner Knowledge Check

If you can choose the transport and authentication model, set a safe version and cipher policy, and scope a deployment claim to its evidence, you can stop here. Continue to Under the Hood for the handshake mechanics, record protection, and failure modes.

15.3.1 The Handshake Establishes a Verified Transcript

Before any application data flows, the handshake authenticates the peer, agrees on fresh key material, and negotiates parameters such as version, cipher suite, and key-exchange group. Crucially, it authenticates a transcript of that negotiation: when both sides verify the Finished messages, any attacker tampering with or downgrading the offered parameters is detected. This is why a downgrade to a weak version or cipher does not pass silently when the configuration enforces a minimum.

TLS 1.3 (RFC 8446) modernized this: its standard cipher suites use AEAD, ephemeral (EC)DHE provides forward secrecy, and static RSA key transport was removed. PSK-only handshakes do not provide forward secrecy. Most of the handshake after the server’s first message is itself encrypted, and the normal handshake completes in a single round trip. An optional 0-RTT “early data” mode sends data before that round trip completes, with replay risk. TLS 1.2 (RFC 5246) can be safe when configured with AEAD cipher suites and ephemeral ECDHE for forward secrecy, avoiding legacy options such as static RSA key exchange, RC4, and the known CBC-padding pitfalls.

15.3.2 A Cipher Suite Is a Bundle

A cipher suite is not one algorithm. In TLS 1.3 it selects an AEAD cipher (such as AES-GCM, AES-CCM, or ChaCha20-Poly1305) and a hash for key derivation and transcript binding; key exchange and authentication are negotiated separately. TLS 1.2 suite names also include key exchange and authentication. Naming “AES” says nothing about how keys are agreed or how the peer is authenticated, so a review records the version, suite, key-exchange mode, and authentication method.

15.3.3 Record Protection and Replay

After the handshake, application data is split into records, each protected with the negotiated AEAD: the record is encrypted and carries an authentication tag, and the receiver must reject a record whose tag fails before using any plaintext. TLS detects replayed or reordered records through implicit sequence numbers bound to record protection (RFC 8446 §5.3; RFC 5246 §6.2.3); TCP also provides ordered delivery. DTLS datagrams may be lost, reordered, or duplicated, so the receiver uses per-record sequence numbers to detect duplicates; a sliding anti-replay window can also reject records that fall outside its acceptance range.

15.3.4 DTLS, Datagrams, and Denial of Service

DTLS adds handling a stream does not need: retransmission and reordering of handshake messages and per-record sequence numbers. DTLS 1.3 record processing rejects duplicate sequence numbers (RFC 9147 §4.5.1), while §3.4 describes replay detection as optional; a sliding anti-replay window is a common implementation. When enabled, a cookie or return-routability exchange makes a client prove it can receive at its claimed source address before the server commits substantial state or sends large responses. This resists denial of service and amplification from spoofed source addresses. Verify replay handling and the deployment’s cookie policy. None of this makes a state-changing datagram idempotent: if a repeated command would be unsafe, the application still needs command identifiers or a deduplication policy of its own.

15.3.5 0-RTT Early Data and Resumption

Session resumption reduces handshake cost, and TLS 1.3 can carry 0-RTT early data in the client’s first flight, before the handshake finishes. The trade-off is concrete: early data is replayable by an attacker who captured it, and it is not forward-secret. Applications must restrict early data to safe, idempotent operations and keep state-changing actions such as unlocks, configuration changes, firmware actions, and payments out of it.

15.3.6 Where the Protection Ends

TLS and DTLS protect a single connection hop, between the two endpoints of the transport session. If a broker, proxy, gateway, or load balancer terminates the session, that component sees plaintext, and protection beyond it is a separate decision (for example, end-to-end object or payload protection). Confidentiality on the wire is not the same as confidentiality in the terminating service’s memory or logs, so a review names the component that terminates the session and who reads the data after it.

15.3.7 Common Pitfalls

• Confusing encryption with authentication: An encrypted connection can still reach the wrong peer. Check the certificate or PSK identity to establish the intended peer.
• Claiming end-to-end security past a terminating proxy or broker: TLS and DTLS protect a hop; the session terminator reads plaintext.
• Allowing plaintext or weak-version fallback: A failed or blocked handshake must fail closed rather than drop to cleartext or an obsolete version.
• Using 0-RTT early data for state-changing commands: Early data is replayable and not forward-secret, making it unsafe for unlocks, configuration, firmware, or payments.
• Forgetting DTLS replay and DoS handling: Datagrams can be lost, reordered, or duplicated. Without the anti-replay window and cookie exchange, duplicates and spoofed-source floods get through.

15.3.8 Under-the-Hood Knowledge Check

At this depth, TLS and DTLS are a set of independent guarantees layered on one connection: an authenticated, transcript-bound handshake; forward-secret key agreement; AEAD-protected records that are rejected before use on failure; anti-replay state that DTLS must maintain over lossy datagrams; and a clear plaintext boundary where the session terminates. A trustworthy review records each guarantee and its negative test, instead of accepting a single “it uses TLS” label.