By the end of this section, you will be able to:
DTLS (Datagram Transport Layer Security) adds encryption to UDP, making it safe for IoT devices to send data without eavesdroppers. Think of it as putting your postcard in a sealed envelope – the message still travels quickly (like UDP), but now only the intended recipient can read it.
“DTLS is like putting our UDP postcards in sealed envelopes,” said Sammy the Sensor. “We still get the speed of UDP, but now nobody can read our messages or tamper with them along the way.”
“The handshake is the expensive part,” explained Max the Microcontroller. “When two devices first connect, they exchange certificates and agree on encryption keys. This takes about 620 bytes. But with session resumption, reconnecting only costs 200 bytes – a 68 percent reduction in bytes and about 62 percent less energy!”
“Cookie-based DoS prevention is clever,” added Lila the LED. “Before doing the full handshake, the server sends a cookie tied to the client’s IP address. Only clients who can echo it back – proving they received it at that IP – get to proceed. This stops attackers from overwhelming the server with fake handshake requests using spoofed IPs – especially important for IoT gateways with limited resources.”
“For sensors that need 5 to 10 year battery life, DTLS session resumption is essential,” said Bella the Battery. “Without it, every reconnection after sleep would require a full handshake. With it, devices can quickly resume encrypted communication after waking up, keeping both security and battery life intact.”
Before diving into this chapter, you should be familiar with:
In one sentence: DTLS brings TLS-level security to UDP, enabling encrypted communication for IoT without TCP’s overhead.
Remember this: DTLS session resumption cuts handshake bytes by 68% (620→200 bytes) and energy by ~62%, making secure UDP practical for battery-powered sensors.
Prerequisites:
Deep Dives:
Applications:
DTLS provides security services for UDP communications, based on TLS (Transport Layer Security).
TLS (used with TCP) provides: - Encryption: Confidentiality - Authentication: Verify endpoints - Integrity: Detect tampering
But TLS requires TCP (connection-oriented, reliable)
Problem: Many IoT apps use UDP (low overhead, real-time)
Solution: DTLS = TLS adapted for UDP
Based on TLS 1.2 / 1.3:
Key Differences from TLS:
Provides:
Overhead:
DTLS Handshake Steps:
Overhead: 6-10 messages across 3-4 RTTs (vs 1 RTT for TLS 1.3, 2 RTTs for TLS 1.2 over TCP)
Why more overhead?
Note: DTLS 1.3 (RFC 9147) removes HelloVerifyRequest. When DoS protection is needed, the server issues a HelloRetryRequest carrying a cookie extension. Without the cookie exchange, DTLS 1.3 completes in 1 RTT (matching TLS 1.3); with the optional cookie exchange it requires 2 RTTs — a significant improvement over DTLS 1.2’s 3-4 RTTs.
Why sequence numbers are critical:
Replay attack scenario (without sequence numbers): 1. Attacker captures: Encrypted “Unlock door” command (Packet A) 2. Legitimate user: Locks door 3. Attacker: Retransmits Packet A 4. Door: Receives encrypted command, decrypts, unlocks! - Encryption doesn’t help - packet is valid - Attacker didn’t need to decrypt to cause action
DTLS protection:
Sliding window for handling UDP reordering:
Recent sequences: [95, 96, 97, 98, 99, 100]
Packet arrives sequence #97:
- Check: Within window? Yes
- Check: Already seen #97? Yes
- Action: Reject (duplicate)
Packet arrives sequence #101:
- Check: > last sequence (100)? Yes
- Action: Accept, update window [96-101]
Packet arrives sequence #50:
- Check: Too old (outside window)
- Action: Reject (possible replay)CoAP over DTLS:
Other Uses:
Resource Constraints:
Solutions:
Two options for securing IP traffic:
DTLS (Transport/Application Layer): - Secures specific application (e.g., CoAP) - Application controls security - More flexible (can choose per-connection)
IPsec (Network Layer): - Secures all IP traffic - Transparent to applications - OS/firmware controls security - More complex to configure
IoT Recommendation: DTLS for application-specific security (CoAP), IPsec for VPN/infrastructure
Option A (TLS over TCP): Full TLS 1.3 handshake requires 1-2 RTT (100-200ms typical). Header overhead: 5 bytes TLS record + 20 bytes TCP = 25 bytes minimum. Connection-oriented with automatic retransmission. Memory: 4-16 KB for connection state and buffers. Best cipher performance with hardware acceleration.
Option B (DTLS over UDP): DTLS 1.2 handshake requires 3-4 RTT (300-400ms typical) — 3 RTTs for PSK without retransmissions, 4 RTTs when the HelloVerifyRequest cookie exchange is included. Header overhead: 13 bytes DTLS record + 8 bytes UDP = 21 bytes. Connectionless with application-managed retries. Memory: 2-8 KB (no TCP buffers). Session resumption reduces subsequent handshakes to 1 RTT.
Decision Factors: Choose TLS/TCP when network is reliable (Wi-Fi, Ethernet), payload is large (>1 KB), or using existing TCP-based protocols (HTTPS, MQTT). Choose DTLS/UDP when battery constrained (DTLS session resumption + UDP saves power), network is lossy (UDP handles loss at application layer with less blocking), or real-time requirements exist (no head-of-line blocking). For CoAP deployments, DTLS is the standard choice (CoAPS on port 5684).
Option A (Certificate-based DTLS): Full X.509 certificate exchange during handshake. Certificate size: 500-2000 bytes per certificate (server + optionally client). Handshake cost: 6-10 packets, 2-4 seconds on constrained devices. CPU: RSA-2048 verification ~600ms on ARM Cortex-M4, ECDSA-256 ~100ms. Provides identity verification and perfect forward secrecy.
Option B (PSK DTLS): Pre-shared symmetric key (16-32 bytes) provisioned during manufacturing. Handshake cost: 4-6 packets, 200-500ms on constrained devices. CPU: symmetric operations only (~1ms). No certificates transmitted. Memory: 32-64 bytes for PSK storage vs 2-4 KB for certificate handling.
Decision Factors: Choose certificate-based when devices communicate with unknown servers (cloud services, public APIs), strong identity binding required (compliance), or PKI infrastructure exists. Choose PSK when manufacturing can provision keys securely, devices connect to known gateways only, constrained devices with <32 KB RAM, or ultra-low power requirements demand fastest handshake. Hybrid approach: PSK for routine communication, certificate for initial provisioning or firmware updates.
Session resumption is critical for energy-efficient DTLS in IoT.
Without session resumption:
With session resumption:
Session resumption’s energy savings compound over time. For a sensor sending n messages per day:
\[E_{\text{daily, no resumption}} = n \times 130\text{ mJ}\] \[E_{\text{daily, with resumption}} = 130\text{ mJ} + (n-1) \times 50\text{ mJ}\]
Savings fraction approaches 62% as n increases:
\[\text{Savings} = \frac{n \times 130 - [130 + (n-1) \times 50]}{n \times 130} = \frac{80(n-1)}{130n}\]
For n=100 messages/day:
\[E_{\text{no resumption}} = 13{,}000\text{ mJ} = 13\text{ J}\] \[E_{\text{with resumption}} = 130 + 4{,}950 = 5{,}080\text{ mJ} = 5.08\text{ J}\] \[\text{Actual savings} = 61\%\]
Over 5 years: \(13\text{ J/day} \times 1825\text{ days} = 23{,}725\text{ J}\) vs \(9{,}271\text{ J}\) - a 14.5 kJ difference that extends battery life from 3 years to 8 years.
| Protocol | Messages | Bytes | RTT | Time (100ms RTT) | Energy |
|---|---|---|---|---|---|
| None (Unencrypted) | N/A | 0 | 0 | 0 ms | 0 uJ |
| DTLS 1.2 + PSK | 6–8 | 620 | 3–4 | 300–400 ms | 4,500 uJ |
| DTLS 1.2 + Certificates | 6–8 | 1,790 | 3–4 | 300–400 ms | 4,500 uJ |
| DTLS Session Resumption | 4 | 200 | 1 | 100 ms | 1,500 uJ |
RTT count includes the HelloVerifyRequest cookie exchange (adds 1 RTT in DTLS 1.2). Message count varies with retransmission; 6 is the minimum for PSK without cookie exchange, 8 with it. DTLS 1.3 reduces fresh handshakes to 1 RTT (no HelloVerifyRequest).
Key insight: Session resumption reduces handshake from 620 bytes to 200 bytes (68% byte reduction), cutting handshake energy from 4,500 μJ to 1,500 μJ (67% energy reduction).
Scenario: A city deploys 2,000 parking occupancy sensors using CoAP over DTLS. Each sensor sends a 40-byte status update every 60 seconds. Sensors run on a 2,400 mAh AA lithium battery at 3.0V. The network uses an nRF52840 radio (8 mA TX current, 5 mA RX current).
Question: What is the battery lifetime with and without session resumption? Which authentication method (PSK vs certificate) should the city choose?
Step 1: Full handshake energy per connection (certificate-based)
Step 2: Data transmission energy per message
Step 3: Battery lifetime WITHOUT session resumption
Every message requires a full handshake (connection-per-message pattern):
Step 4: Battery lifetime WITH session resumption (PSK)
First message per wake cycle uses abbreviated handshake; PSK eliminates certificate overhead:
In practice, battery self-discharge limits lifetime to ~10 years, but the margin means the radio is not the bottleneck.
Step 5: PSK vs Certificate decision
| Factor | PSK | Certificate |
|---|---|---|
| Handshake energy | 0.35 mAs | 2.24 mAs |
| Handshake bytes | 200 B | 1,790 B |
| Battery impact | 41 yr theoretical | 7.2 yr theoretical |
| Provisioning | Keys loaded at factory | PKI infrastructure needed |
| Scalability | 2,000 keys to manage | Certificate authority scales better |
| Rotation | Manual firmware update | Automated via CRL/OCSP |
Recommendation: PSK for this deployment. The sensors connect to known city gateways (not arbitrary cloud endpoints), and 2,000 devices are manageable with PSK provisioning. The 6x energy savings justify the provisioning overhead.
Unencrypted CoAP is tempting for battery savings, but parking sensors handle billing data. An attacker spoofing “space occupied” messages could prevent legitimate parking, costing the city revenue. An attacker spoofing “space available” could direct drivers to occupied spaces, causing congestion. DTLS with PSK adds 0.35 mAs per handshake – about 7x higher than the 0.05 mAs data-only cost, but the total of 0.40 mAs per message is still well within the battery budget. The cost of a security breach (lost revenue, legal liability, citizen trust) far exceeds the cost of slightly larger batteries or shorter replacement intervals.
DTLS (Datagram Transport Layer Security):
DTLS Features:
Energy Optimization:
When to Use DTLS:
Depends on:
Enables:
Related concepts:
Security fundamentals:
External resources:
Mobile IoT devices on LTE may change UDP source port when the NAT binding expires (typically after 30–60 seconds of inactivity). Standard DTLS 1.2 identifies sessions by IP:port, so a port change appears as a new client and triggers full re-handshake (3–8 KB overhead). DTLS 1.3 Connection IDs (RFC 9146) allow the session to survive port changes. For LTE-M devices with PSM, either use DTLS CID or accept full re-handshake on wakeup and implement efficient session resumption.
tinydtls had a critical vulnerability (CVE-2021-41030) allowing remote code execution via malformed DTLS packet. The Eclipse tinydtls project had long periods of inactivity with unpatched vulnerabilities. Before using tinydtls in production, verify the version is up-to-date and check CVE databases. Consider WolfSSL or mbedTLS for production IoT devices as they have more active security maintenance and commercial support options.
DTLS records that exceed the network path MTU (typically 1280–1500 bytes) are IP-fragmented. If any fragment is lost, the entire DTLS record is lost and must be retransmitted. DTLS does not fragment at the record layer — it sends records as single UDP datagrams. For large certificate transmissions, DTLS fragments at the handshake message layer (fragment_offset + fragment_length). Limit DTLS application data records to <1232 bytes (IPv6 minimum MTU 1280 - 40 IP - 8 UDP - DTLS record header) to avoid IP fragmentation.
DTLS sessions have a finite lifetime (typically 24 hours for TLS 1.2 session tickets). IoT devices that send data infrequently (e.g., daily meter readings) may find their DTLS session expired when they wake up. Firmware must handle session expiry gracefully: detect expired session (DTLS alert 0x2A: handshake_failure or alert 0x5A: bad_certificate), fall back to full handshake, and retry the failed operation. Never hard-fail on DTLS session expiry — treat it as a recoverable condition.
| Chapter | Why Read It | Link |
|---|---|---|
| Transport Protocol Selection | Apply everything from this chapter: choose between TCP/TLS, UDP/DTLS, or QUIC for a concrete IoT deployment scenario | transport-protocols-selection.html |
| CoAP Fundamentals | See how CoAP is designed for DTLS (CoAPS on port 5684) — the primary IoT application of DTLS in practice | ../app-protocols/coap-fundamentals.html |
| CoAP Security Applications | Implement CoAPS end-to-end: configure DTLS cipher suites, PSK provisioning, and session resumption in CoAP stacks | ../app-protocols/coap-security-applications.html |
| TLS and DTLS in Detail | Compare DTLS record layer and cipher suite selection against TLS 1.3 in depth, including AEAD modes and key schedules | ../cryptography/encryption-tls-dtls.html |
| Secure IoT Communications | Evaluate where DTLS fits within the broader IoT security architecture across network, transport, and application layers | ../cryptography/cyber-security-secure-communications.html |
| Energy and Power Management | Calculate battery lifetime budgets that integrate DTLS handshake energy with sensor duty cycles and sleep strategies | ../../9-engineering/energy-power/energy-power-overview.html |