%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22'}}}%%
graph TB
subgraph "DTLS Security Architecture"
App["Application Layer<br/>CoAP, Custom Apps"]
DTLS["DTLS Layer"]
UDP["UDP Transport"]
IP["IP Network"]
App --> DTLS
DTLS --> UDP
UDP --> IP
end
subgraph "DTLS Security Features"
F1["Encryption<br/>AES-GCM"]
F2["Authentication<br/>Certificates/PSK"]
F3["Integrity<br/>HMAC"]
F4["Replay Protection<br/>Sequence numbers"]
DTLS --> F1
DTLS --> F2
DTLS --> F3
DTLS --> F4
end
subgraph "UDP Adaptations"
A1["Cookie Mechanism<br/>DoS protection"]
A2["Explicit Sequence<br/>Record number"]
A3["Fragmentation<br/>Handle large records"]
A4["Retransmission<br/>Handle packet loss"]
DTLS --> A1
DTLS --> A2
DTLS --> A3
DTLS --> A4
end
style App fill:#E67E22,color:#fff
style DTLS fill:#2C3E50,color:#fff
style UDP fill:#16A085,color:#fff
style IP fill:#16A085,color:#fff
style F1 fill:#2C3E50,color:#fff
style F2 fill:#2C3E50,color:#fff
style F3 fill:#2C3E50,color:#fff
style F4 fill:#2C3E50,color:#fff
style A1 fill:#16A085,color:#fff
style A2 fill:#16A085,color:#fff
style A3 fill:#16A085,color:#fff
style A4 fill:#16A085,color:#fff
747 DTLS Fundamentals and Architecture
747.1 Learning Objectives
By the end of this chapter, you will be able to:
- Understand DTLS Architecture: Explain how Datagram TLS provides security over UDP for real-time IoT applications
- Compare TLS and DTLS: Differentiate between TCP-based TLS and UDP-based DTLS for different use cases
- Analyze Protocol Properties: Understand key exchange, encryption, and integrity mechanisms in DTLS
- Evaluate Use Cases: Determine when DTLS is appropriate versus TLS for IoT applications
TipMVU: Minimum Viable Understanding
Core concept: DTLS (Datagram TLS) provides TLS-equivalent encryption over UDP, enabling secure real-time IoT communication without TCP’s latency overhead.
Why it matters: CoAP and other UDP-based IoT protocols cannot use standard TLS; without DTLS, your sensor data travels unencrypted and vulnerable to interception.
Key takeaway: Use DTLS for CoAP (port 5684), video streaming, and real-time telemetry; use regular TLS over TCP only for file transfers and critical commands where reliability trumps speed.
747.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- CoAP Fundamentals and Architecture: Understanding CoAP’s UDP-based design and port 5684 (CoAPs) is essential since DTLS is the primary security layer for CoAP
- IoT Protocols Fundamentals: Knowledge of UDP vs TCP transport differences and the protocol stack helps you understand why DTLS adapted TLS for datagram networks
- Networking Basics: Familiarity with encryption concepts, handshakes, and client-server security models provides foundation for DTLS authentication modes
NoteHistorical Context: How TLS Evolved for IoT
SSL Origins (1995): Netscape developed SSL 2.0/3.0 for securing web browsing. These protocols assumed reliable TCP transport and desktop-class computing power. A full SSL 3.0 handshake required 2 round-trip times (RTT) - acceptable for web pages but problematic for real-time applications.
TLS Standardization (1999-2008): The IETF standardized TLS 1.0 (1999), 1.1 (2006), and 1.2 (2008) as SSL’s successor. TLS 1.2 still required 2-RTT handshakes with RSA key exchange, or 2-RTT with optional DHE for forward secrecy. These protocols dominated web security but remained tied to TCP’s reliable delivery model.
The UDP Challenge (2006): Real-time applications like VoIP (Voice over IP) needed encryption but couldn’t tolerate TCP’s head-of-line blocking. When a single packet was lost, TCP would stall the entire stream waiting for retransmission - unacceptable for voice calls. DTLS 1.0 (RFC 4347) adapted TLS semantics for unreliable UDP transport, adding:
- Cookie mechanism: Stateless DoS protection (prevents amplification attacks)
- Explicit sequence numbers: Replay protection without TCP’s implicit sequencing
- Handshake retransmission: Timer-based retransmits for lost handshake messages
- Message fragmentation: Handle certificates larger than MTU
DTLS 1.0 required 3-RTT handshakes (extra round-trip for cookie exchange).
CoAP Adoption (2014): When the IETF published CoAP (RFC 7252) as the “HTTP for IoT,” they mandated DTLS as the security layer. CoAP runs over UDP to minimize overhead on constrained devices - sensors with 10KB RAM couldn’t afford TCP’s connection state. CoAP Secure (CoAPs) uses port 5684 with mandatory DTLS, making DTLS the de facto security standard for constrained IoT.
Modern Security - TLS 1.3 (2018): RFC 8446 brought major improvements:
- 1-RTT handshakes: Client sends key share in first message (vs 2-RTT in TLS 1.2)
- 0-RTT resumption: Cached sessions can send data immediately (replay-vulnerable)
- Mandatory forward secrecy: Removed RSA key exchange entirely
- Cipher suite cleanup: Only 5 AEAD ciphers remain (vs 300+ in TLS 1.2)
For IoT, 1-RTT means 50-150ms faster connections - significant battery savings.
IoT Optimizations (2020+): DTLS 1.3 (RFC 9147, 2022) brought TLS 1.3’s improvements to datagram transport:
- 1-RTT handshake: Matches TLS 1.3 performance (down from 3-RTT in DTLS 1.2)
- Connection ID (RFC 9146): Sessions survive IP address changes (NAT rebinding, mobile handoff)
- Reduced handshake size: Critical for LoRaWAN and other bandwidth-constrained links
- AEAD-only ciphers: Simplified implementation for resource-constrained MCUs
RTT Comparison Across Protocol Versions:
| Protocol | Full Handshake | Session Resumption | Notes |
|---|---|---|---|
| SSL 3.0 | 2-RTT | 1-RTT | Deprecated (POODLE attack) |
| TLS 1.2 | 2-RTT | 1-RTT | Still common, RSA key exchange allowed |
| TLS 1.3 | 1-RTT | 0-RTT | Modern standard, mandatory PFS |
| DTLS 1.0 | 3-RTT | 2-RTT | Extra RTT for cookie exchange |
| DTLS 1.2 | 3-RTT | 1-RTT | Current IoT standard |
| DTLS 1.3 | 2-RTT (with cookie) | 1-RTT | Emerging, Connection ID support |
Why This Matters for IoT: Standard TLS assumes TCP reliability (guaranteed delivery, ordering) and desktop compute power (RSA acceleration, GB of RAM). IoT devices face the opposite constraints:
- UDP-based protocols: CoAP, many industrial protocols run over UDP for lower latency
- Constrained resources: 32KB RAM devices can’t buffer TCP retransmission queues
- Battery sensitivity: Each RTT means radio-on time - 3-RTT vs 1-RTT is 3x battery drain
- Mobility: Devices change IP addresses; Connection ID preserves sessions
DTLS and IoT-specific TLS profiles (like those in Thread and Matter) address these constraints, making secure real-time communication possible on devices smaller than a postage stamp.
747.3 Datagram Transport Layer Security (DTLS)
DTLS provides security services for UDP communications, based on TLS (Transport Layer Security).
747.3.1 Why DTLS?
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
TipAlternative View: TLS vs DTLS Handshake Comparison
This variant shows the key difference in handshake flow between TLS (over TCP) and DTLS (over UDP) - critical for understanding the latency trade-offs.
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3', 'fontSize': '10px'}}}%%
sequenceDiagram
box rgb(46, 125, 50) TLS 1.2 over TCP (2-RTT)
participant TC as Client
participant TS as Server
end
box rgb(39, 60, 117) DTLS 1.2 over UDP (3-RTT with cookie)
participant DC as Client
participant DS as Server
end
Note over TC,TS: TLS: TCP guarantees delivery
TC->>TS: ClientHello
TS->>TC: ServerHello + Cert + KeyExch
TC->>TS: ClientKeyExch + ChangeCipher
TS->>TC: ChangeCipherSpec
Note over TC,TS: 2 RTT then encrypted data
Note over DC,DS: DTLS: Cookie prevents DoS
DC->>DS: ClientHello
DS->>DC: HelloVerifyRequest + Cookie
DC->>DS: ClientHello + Cookie
DS->>DC: ServerHello + Cert + KeyExch
DC->>DS: ClientKeyExch + ChangeCipher
DS->>DC: ChangeCipherSpec
Note over DC,DS: 3 RTT then encrypted data
Key Insight: DTLS 1.3 reduces this to 2-RTT, matching TLS 1.3 performance while maintaining DoS protection.
747.3.2 DTLS Characteristics
747.4 DTLS Properties
Based on TLS 1.2 / 1.3: - Same security properties as TLS - Adapted for datagram (unreliable) transport
Key Differences from TLS: - Handles packet loss: Retransmits handshake messages if lost - Handles reordering: Sequence numbers within records - No stream abstraction: Works with discrete datagrams - Replay protection: Prevents replay attacks
Provides: - Encryption: AES, ChaCha20 (symmetric) - Authentication: Certificates, Pre-Shared Keys (PSK) - Integrity: HMAC, AEAD (Authenticated Encryption) - Key Exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
Overhead: - Handshake: 6-10 datagrams (vs 3-6 for TLS) - Record: 13 bytes header + MAC/tag (vs 5 bytes TLS) - Larger than UDP alone, but secure
747.4.1 DTLS Use Cases in IoT
CoAP over DTLS: - CoAP: Constrained Application Protocol (RESTful for IoT) - Port 5684: CoAPS (CoAP Secure) = CoAP over DTLS - Cipher suite: AES-CCM, PSK (Pre-Shared Key) common
Other Uses: - VPN: OpenVPN can use DTLS - WebRTC: Real-time communications - Gaming: Low-latency secure multiplayer - VoIP: Secure voice over IP (SRTP)
747.4.2 DTLS Challenges for IoT
Resource Constraints: - Handshake cost: 6-10 messages x (radio on time) - Memory: TLS/DTLS state requires RAM - Crypto: Public key operations (RSA, ECC) CPU-intensive - Code size: TLS/DTLS library (50-200 KB)
Solutions: - PSK (Pre-Shared Keys): No public key crypto in handshake - Session resumption: Reuse previous session (skip full handshake) - Connection ID: Survive address changes (mobility) - Hardware crypto: Use hardware accelerators (AES-NI, etc.)
TipDTLS vs IPsec
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
747.5 Knowledge Check
Test your understanding of these networking concepts.
NoteQuiz: DTLS Sequence Numbers and Replay Protection
Scenario: Your smart doorbell uses DTLS to encrypt “unlock door” commands sent from your phone. An attacker parks outside, captures encrypted packet #100 containing the unlock command, and waits. After you lock the door and leave, the attacker retransmits the captured packet #100.
Think about: - The packet is still validly encrypted–why doesn’t it work? - How does the doorbell distinguish between legitimate retransmission (lost packet) and malicious replay? - What happens when packets arrive out-of-order due to network jitter?
Key Insight: DTLS uses explicit sequence numbers (48-bit counter in record header) to prevent replay attacks. Each packet has a unique, incrementing sequence number. The receiver maintains a “sliding window” of recently seen sequences:
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 actionDTLS protection with sequence numbers:
Processing Steps: 1. Packet arrives with sequence #100 2. Server checks: Last seen sequence = #99 3. Accept: #100 > #99 4. Reject: If #100 arrives again (replay)
Replay Attack Prevention: 1. Attacker retransmits sequence #100 2. Server: Already processed #100, reject 3. Attack failed!
Additional uses: 1. IV derivation: Some ciphers use sequence number as nonce/IV 2. Sliding window: Track recent sequence numbers to handle reordering (UDP packets may arrive out-of-order) 3. Authentication: Sequence number included in MAC calculation prevents tampering
Sequence number management:
Sliding window (64 packets):
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)Real-world vulnerability: Smart locks using UDP without replay protection vulnerable to packet replay. DTLS sequence numbers essential for security.
Standard: RFC 6347 (DTLS 1.2), RFC 9147 (DTLS 1.3) mandate sequence number usage.
Question: Which DTLS mechanism most directly prevents an attacker from replaying a previously captured encrypted command (e.g., “unlock door”)?
Explanation: B. DTLS includes explicit sequence numbers in the record layer and tracks recently seen values. Duplicates or values outside the acceptable window are rejected, stopping “record-and-replay” attacks even when the ciphertext remains valid.
Question: Packets can arrive out of order on UDP networks. How does DTLS handle reordering without disabling replay protection?
Explanation: C. A receive window allows some out-of-order delivery while still rejecting duplicates and very old packets (common replay patterns). This balances UDP realities with strong security guarantees.
747.6 Summary
DTLS Purpose: - Provides TLS security for UDP-based applications - Essential for CoAP, VoIP, WebRTC, and real-time IoT
Architecture: - Layered between application (CoAP) and transport (UDP) - Adds cookie mechanism, sequence numbers, fragmentation, retransmission
Key Properties: - Same security as TLS: encryption, authentication, integrity - Adapted for unreliable transport: handles loss and reordering - Higher overhead than plain UDP, but necessary for security
IoT Fit: - Use DTLS for latency-sensitive, loss-tolerant applications - Use TLS/TCP for reliable, ordered data delivery - PSK mode for constrained devices, certificates for enterprise
747.7 What’s Next?
Continue to DTLS Handshake Protocols to learn the detailed handshake process for DTLS 1.2 and 1.3, including the cookie mechanism for DoS protection and how TLS 1.3 improvements apply to datagram transport.