734  DTLS: Securing UDP for IoT

NoteLearning Objectives

By the end of this section, you will be able to:

• Understand DTLS (Datagram Transport Layer Security) for securing UDP
• Compare DTLS to TLS and understand when to use each
• Analyze DTLS handshake overhead and optimization strategies
• Implement session resumption for energy-efficient secure communication
• Understand replay protection and cookie-based DoS prevention

734.1 Prerequisites

Before diving into this chapter, you should be familiar with:

• Transport Protocol Fundamentals: Understanding TCP vs UDP characteristics is essential since DTLS adapts TLS security for UDP’s connectionless, unreliable transport
• Basic cryptography concepts: Familiarity with encryption, authentication, and key exchange helps understand DTLS’s security guarantees
• IoT security requirements: Understanding why encryption and authentication matter for IoT devices

NoteKey Takeaway

In one sentence: DTLS brings TLS-level security to UDP, enabling encrypted communication for IoT without TCP’s overhead.

Remember this: DTLS session resumption can reduce handshake overhead by 67%, making secure UDP practical for battery-powered sensors that need encryption.

---

NoteRelated Chapters

Prerequisites: - Transport Protocol Fundamentals - TCP/UDP basics - Encryption Principles - Cryptography basics

Deep Dives: - Transport Protocols Overview - Index page - Protocol Selection - Choosing protocols - Security Overview - IoT security concepts

Applications: - CoAP Protocol - CoAP uses DTLS for CoAPS

734.2 Datagram Transport Layer Security (DTLS)

DTLS provides security services for UDP communications, based on TLS (Transport Layer Security).

734.2.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

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
graph TB
    subgraph "Security Options"
        TCP[TCP] --> TLS[TLS<br/>Transport Layer Security]
        UDP[UDP] --> DTLS[DTLS<br/>Datagram TLS]
    end

    subgraph "DTLS Features"
        F1[Encryption<br/>Confidentiality]
        F2[Authentication<br/>Verify Endpoints]
        F3[Integrity<br/>Detect Tampering]
        F4[Low Overhead<br/>vs TLS/TCP]
    end

    subgraph "IoT Applications"
        A1[CoAPS<br/>CoAP over DTLS]
        A2[WebRTC<br/>Real-time Comms]
        A3[OpenVPN<br/>Secure VPN]
    end

    DTLS --> F1 & F2 & F3 & F4
    F1 & F2 & F3 & F4 --> A1 & A2 & A3

    style TCP fill:#2C3E50,stroke:#16A085,color:#fff
    style UDP fill:#16A085,stroke:#2C3E50,color:#fff
    style TLS fill:#E67E22,stroke:#16A085,color:#fff
    style DTLS fill:#E67E22,stroke:#16A085,color:#fff
    style F1 fill:#2C3E50,stroke:#16A085,color:#fff
    style F2 fill:#2C3E50,stroke:#16A085,color:#fff
    style F3 fill:#2C3E50,stroke:#16A085,color:#fff
    style F4 fill:#27ae60,stroke:#16a085,color:#fff
    style A1 fill:#E67E22,stroke:#16A085,color:#fff
    style A2 fill:#E67E22,stroke:#16A085,color:#fff
    style A3 fill:#E67E22,stroke:#16A085,color:#fff

Figure 734.1: DTLS security features (encryption, authentication, integrity) enabling secure UDP for CoAP and WebRTC

DTLS brings TLS-level security to UDP, enabling encrypted low-overhead communication for IoT applications

734.2.2 DTLS Characteristics

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

734.2.3 DTLS Handshake

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
sequenceDiagram
    participant C as Client
    participant S as Server

    Note over C,S: DTLS Handshake (with cookie)
    C->>S: 1. ClientHello
    S->>C: 2. HelloVerifyRequest (cookie)
    Note over S: DoS Protection

    C->>S: 3. ClientHello (with cookie)
    S->>C: 4. ServerHello + Certificate
    S->>C: 5. ServerKeyExchange
    S->>C: 6. ServerHelloDone

    C->>S: 7. ClientKeyExchange
    C->>S: 8. ChangeCipherSpec
    C->>S: 9. Finished (encrypted)

    S->>C: 10. ChangeCipherSpec
    S->>C: 11. Finished (encrypted)

    Note over C,S: Secure Channel Established
    C->>S: Application Data (encrypted)
    S->>C: Application Data (encrypted)

Figure 734.2: DTLS handshake sequence with cookie-based DoS protection and certificate exchange for secure channel

DTLS handshake includes cookie exchange for DoS protection, requiring 6-10 round trips vs 1.5-2 for TLS

DTLS Handshake Steps:

1. ClientHello: Client proposes cipher suites
2. HelloVerifyRequest: Server sends cookie (DoS protection)
3. ClientHello (with cookie): Client proves legitimacy
4. Server responds: Certificate, key exchange parameters
5. Client key exchange: Client sends key material
6. Finished messages: Both sides confirm (encrypted)
7. Secure communication: Application data flows encrypted

Overhead: 6-10 round trips (vs 1.5-2 for TLS over TCP)

Why more overhead? - Unreliable transport: Must handle lost handshake packets - Retransmission: DTLS retransmits handshake messages - Cookie mechanism: Extra round trip for DoS protection

734.2.4 DTLS Replay Protection

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor':'#2C3E50','primaryTextColor':'#fff','primaryBorderColor':'#16A085','lineColor':'#16A085','secondaryColor':'#E67E22','tertiaryColor':'#ecf0f1','background':'#ffffff','mainBkg':'#2C3E50','secondBkg':'#16A085','tertiaryBorderColor':'#95a5a6','clusterBkg':'#ecf0f1','clusterBorder':'#95a5a6','titleColor':'#2C3E50','edgeLabelBackground':'#ffffff','nodeTextColor':'#2C3E50'}}}%%
sequenceDiagram
    participant A as Attacker
    participant N as Network
    participant S as Server

    Note over A,S: Normal Communication
    N->>S: Unlock Command<br/>(Encrypted, seq=100)
    S->>S: Process seq=100<br/>Update: last_seen=100
    Note over S: Door Unlocked

    Note over A,S: Replay Attack Attempt
    A->>S: Retransmit captured packet<br/>(Encrypted, seq=100)
    S->>S: Check: seq=100 <= last_seen(100)
    S->>S: REJECT: Replay detected
    Note over S: Door remains locked

    Note over A,S: Attack Failed!

Figure 734.3: DTLS replay attack prevention using sequence numbers to detect and reject retransmitted packets

DTLS sequence numbers prevent replay attacks by tracking processed packets and rejecting duplicates

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: 1. Packet arrives with sequence #100 2. Server checks: Last seen sequence = #99 3. Accept: #100 > #99 (new packet) 4. Update: last_seen = #100 5. If #100 arrives again: REJECT (replay detected)

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)

734.2.5 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)

734.2.6 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

734.3 DTLS Trade-offs

WarningTradeoff: TLS (over TCP) vs DTLS (over UDP)

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 4-6 RTT (400-600ms typical) due to cookie exchange and UDP unreliability. 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).

WarningTradeoff: Full DTLS Handshake vs Pre-Shared Key (PSK)

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.

734.4 Session Resumption

Session resumption is critical for energy-efficient DTLS in IoT.

734.4.1 How Session Resumption Works

1. Initial handshake: Creates session ID and master secret
2. Both parties cache: Session state stored locally
3. Subsequent connections: Reference session ID
4. Skip expensive operations: Reuse master secret
5. Session lifetime: Hours to days (configurable)

734.4.2 Energy Savings

Without session resumption: - Every message: Full handshake (120 mJ) + data transmission (10 mJ) - Energy per message: 130 mJ

With session resumption: - First message: Full handshake (120 mJ) + data (10 mJ) = 130 mJ - Subsequent: Abbreviated handshake (40 mJ) + data (10 mJ) = 50 mJ - Savings: 62% reduction per message after first!

734.4.3 Handshake Cost Analysis

Protocol	Messages	Bytes	RTT	Time (100ms RTT)	Energy
None (Unencrypted)	N/A	0	0	0 ms	0 uJ
DTLS with PSK	6	620	3	300 ms	4,500 uJ
DTLS with Certificates	6	1,790	3	300 ms	4,500 uJ
DTLS Session Resumption	4	200	1	100 ms	1,500 uJ

Key insight: Session resumption reduces handshake from 620 bytes to 200 bytes (68% reduction).

734.5 Knowledge Check

NoteQuiz: DTLS Security

Question: Why does DTLS need explicit sequence numbers in the record header when UDP itself doesn’t guarantee ordering?

Explanation: DTLS sequence numbers provide critical security:

DTLS doesn’t enforce ordering - it just detects replays. Without sequence numbers, an attacker could capture an encrypted “unlock door” command and replay it later. The server would decrypt and execute it because the encryption is valid. With sequence numbers, the server tracks processed packets and rejects duplicates.

Sequence numbers are also used as the nonce/IV in some cipher modes (like AES-GCM), but the primary purpose is replay protection.

Question: DTLS cookies prevent DoS attacks during handshake. How do they work?

Explanation: DTLS cookies implement stateless DoS protection:

Without cookies, an attacker could send thousands of ClientHello messages with spoofed source IPs. The server would allocate state and generate keys for each fake client, exhausting memory.

With cookies: 1. Client sends ClientHello 2. Server generates cookie = HMAC(client_IP, secret) 3. Server responds with HelloVerifyRequest containing cookie 4. Client must return cookie in next ClientHello 5. Server verifies cookie before allocating any state

Attackers can’t spoof IP because they need to receive the HelloVerifyRequest at their real IP to get the cookie. The server allocates state only after verifying the client’s IP is reachable.

Question: A parking sensor network uses DTLS handshakes consuming 120 mJ per handshake. Sensors report every 30 seconds. How can you reduce energy consumption?

Explanation: DTLS session resumption dramatically reduces energy:

Without session resumption: - Every message: Full handshake (120 mJ) + data (10 mJ) = 130 mJ - Per day (2,880 messages): 374 J = 104 mAh

With session resumption: - First message: 130 mJ - Subsequent: Abbreviated (40 mJ) + data (10 mJ) = 50 mJ - Per day: ~144 J = 40 mAh - Savings: 64% reduction!

Session resumption caches the session ID and master secret. Subsequent connections skip expensive key exchange, reducing handshake from 620 bytes to 200 bytes.

Why NOT other answers: - A: Unacceptable for parking billing (security requirement) - B: TCP adds connection overhead, worse than DTLS resumption - D: Changes application requirements, doesn’t optimize protocol

734.6 Summary

TipKey Takeaways

DTLS (Datagram Transport Layer Security): - Secure UDP: Encryption + authentication for datagrams - Based on TLS, adapted for unreliable transport - Overhead: 13+ bytes per record, handshake cost - Best for: Secure CoAP (CoAPS), secure real-time

DTLS Features: - Replay protection: Sequence numbers prevent packet replay - Cookie mechanism: DoS protection during handshake - Session resumption: 67% handshake reduction for repeat connections - PSK support: Faster handshake without certificates

Energy Optimization: - Use PSK instead of certificates (3x faster handshake) - Enable session resumption (62% energy savings) - Consider Connection ID for mobile devices

When to Use DTLS: - CoAP applications requiring security - Real-time communication needing encryption - Battery-powered devices where TCP+TLS is too expensive

734.7 What’s Next?

Continue to Transport Protocol Selection to learn how to choose the right transport protocol for your specific IoT scenario.