24  DTLS Fundamentals and Architecture

In 60 Seconds

DTLS (Datagram Transport Layer Security) adapts TLS encryption for UDP, letting IoT devices secure real-time data like CoAP sensor readings and video streams without TCP’s latency penalty. It provides the same confidentiality, integrity, and authentication guarantees as TLS but handles packet loss and reordering inherent to UDP through explicit sequence numbers and retransmission timers.

Key Concepts

• TLS Record Protocol: Framework for transmitting application data with confidentiality (AES-GCM encryption) and integrity (HMAC or AEAD authentication tag)
• TLS Handshake Protocol: Negotiates cipher suite, authenticates server (and optionally client), and establishes session keys using asymmetric cryptography
• AEAD (Authenticated Encryption with Associated Data): Modern cipher mode combining encryption and authentication in one pass; examples: AES-128-GCM, ChaCha20-Poly1305; eliminates CBC padding oracle vulnerabilities
• Cipher Suite: TLS negotiation parameter specifying: key exchange algorithm (ECDHE), authentication (ECDSA/RSA), bulk cipher (AES-128-GCM), and hash (SHA-256); example: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• Perfect Forward Secrecy (PFS): Property of key exchange algorithms (ECDHE, DHE) where compromise of the server’s long-term private key does not expose past session keys
• X.509 Certificate: Standard format for public key certificates; binds a public key to an identity (subject) with a digital signature from a Certificate Authority (CA)
• SNI (Server Name Indication): TLS extension allowing clients to specify the target hostname before the handshake, enabling virtual hosting of multiple TLS services on one IP address
• DTLS Epoch Number: 16-bit value incremented on key change events; included in DTLS record header to handle records from different key epochs arriving out of order

24.1 Learning Objectives

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

• Explain DTLS Architecture: Describe how Datagram TLS provides security over UDP for real-time IoT applications and identify the protocol layers it occupies
• Compare TLS and DTLS: Distinguish between TCP-based TLS and UDP-based DTLS and justify which is appropriate for different IoT use cases
• Analyze Protocol Properties: Identify key exchange, encryption, and integrity mechanisms in DTLS and assess their overhead on constrained devices
• Select Authentication Modes: Choose between PSK, Raw Public Key, and X.509 certificate modes based on fleet size, resource constraints, and regulatory requirements
• Evaluate Use Cases: Determine when DTLS is appropriate versus TLS for IoT applications and diagnose misconfigurations that reduce security

MVU: 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.

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

For Beginners: Why DTLS Matters for Real-Time IoT

Imagine this scenario: You’re building a smart home security camera that streams video alerts when motion is detected. You need: 1. Security - Encrypted video so neighbors can’t intercept 2. Low latency - Alerts arrive in < 1 second (not 5 seconds later) 3. Reliability - Works even if some packets are lost

The problem: Traditional TLS (used for HTTPS) requires TCP, which adds 50-200ms latency for reliability. For real-time IoT, that’s too slow.

DTLS solves this by providing TLS-level security over fast UDP, making it perfect for CoAP, video streaming, and real-time sensor networks.

24.2.1 The Real-World Problem

Case Study - Smart Doorbell Failure (2019):

• Vendor used unencrypted UDP for video streaming (for speed)
• Security researchers intercepted doorbell video from street
• Saw live feed of when homeowners were away
• Why: Prioritized speed over security

DTLS solution: Encrypted UDP with only 10-20ms added latency (acceptable for doorbells).

24.2.2 DTLS in Simple Terms

Think of DTLS like sending postcards vs registered mail:

24.2.2.1 Traditional Mail Analogy

Method	Speed	Security	Reliability	IoT Equivalent
Postcard (UDP)	Fast	Anyone can read	May get lost	Unencrypted sensor data
Registered Mail (TCP+TLS)	Slow	Sealed envelope	Delivery confirmed	HTTPS API calls
Sealed Postcard (UDP+DTLS)	Fast	Encrypted	May get lost	CoAP, VoIP, streaming

DTLS = Sealed postcard: Fast delivery, encrypted content, but sender doesn’t wait for confirmation.

24.2.3 Why UDP for IoT?

TCP problems for IoT:

Sensor sends temperature reading (50 bytes):
  TCP: Must establish connection (3-way handshake)
       Wait for ACK for every packet
       Retransmit if lost
  Result: 150-300ms latency, 3x more packets

  UDP: Send packet immediately
       Don't wait for response
  Result: 10-50ms latency, 1 packet

Real-world impact:

• Smart thermostat: UDP allows 10 sensors to report every second (TCP would congest network)
• Video doorbell: UDP tolerates 1% packet loss (TCP would stall video waiting for retransmits)
• Industrial sensor mesh: 500 sensors x UDP = scalable, 500 sensors x TCP = network meltdown

24.2.4 DTLS vs TLS Quick Comparison

Feature	TLS (over TCP)	DTLS (over UDP)
Use Case	Web browsing, downloads	CoAP, VoIP, video, gaming
Latency	100-300ms	10-50ms
Packet Loss	Retransmits (delays)	Tolerates loss
Connection	Persistent	Connectionless
Overhead	Low (5 byte header)	Higher (13 byte header)
Complexity	Simpler	More complex (handles loss)
IoT Fit	APIs, firmware updates	Real-time sensors, streaming

24.2.5 When to Use DTLS

Perfect for:

• CoAP (Constrained Application Protocol) - RESTful API for IoT
• WebRTC - Video calls, screen sharing
• VoIP - Voice over IP (Skype, Zoom audio)
• Real-time telemetry - Sensor data that tolerates some loss
• Gaming - Multiplayer game state synchronization

NOT suitable for:

• File transfers - Use TCP+TLS (reliability matters)
• Firmware updates - Use TCP+TLS (can’t afford packet loss)
• Database queries - Use TCP+TLS (need guaranteed delivery)
• Critical commands - Use TCP+TLS (door unlock, medical device control)

24.2.6 DTLS in Action: Smart Home Example

Scenario: Smart light bulb receives “turn on” command via CoAP over DTLS

Phone -> Wi-Fi -> Router -> Light Bulb
  |       |       |        |
CoAP    Wi-Fi   Gateway   CoAP
DTLS   (WPA3)            DTLS
UDP                      UDP
IPv6                     IPv6

Without DTLS (insecure):

Packet sniffed on Wi-Fi: "coap://bulb.local/light ON"
Neighbor sees command in plain text
Neighbor replays command -> lights flicker

With DTLS (secure):

Packet sniffed on Wi-Fi: "encrypted gibberish..."
Neighbor sees encrypted gibberish
Neighbor replays -> Rejected (sequence number already seen)

Bottom line: DTLS lets you build fast, secure IoT apps without the overhead of TCP.

Sensor Squad: The Sealed Postcard!

“DTLS is my security blanket,” said Sammy the Sensor. “I send my data over UDP because it is fast and light. But without encryption, anyone with a radio receiver could read my temperature readings. DTLS encrypts them without forcing me to use TCP.”

“Think of it as a sealed postcard,” explained Max the Microcontroller. “Regular UDP is like a postcard – fast delivery, but anyone can read it. TCP plus TLS is like registered mail – secure and reliable, but slow. DTLS gives us a sealed postcard – fast AND private!”

“The performance overhead is surprisingly small,” added Lila the LED. “DTLS adds only 10 to 20 milliseconds of latency per packet. For a security camera streaming video or a sensor sending readings every second, that is completely acceptable.”

“CoAP uses DTLS on port 5684 for secure communication,” said Bella the Battery. “Without DTLS, our sensor data would travel in plain text. With DTLS, we get the same encryption strength as HTTPS websites, but over fast, lightweight UDP. Best of both worlds!”

Historical 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 (2-RTT with cookie): Reduces DTLS 1.2’s 3-RTT; without the DoS cookie it matches TLS 1.3 performance
• 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	1-RTT	Extra RTT for cookie exchange; deprecated
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:

1. UDP-based protocols: CoAP, many industrial protocols run over UDP for lower latency
2. Constrained resources: 32KB RAM devices can’t buffer TCP retransmission queues
3. Battery sensitivity: Each RTT means radio-on time - 3-RTT vs 1-RTT is 3x battery drain
4. 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.

24.3 Datagram Transport Layer Security (DTLS)

Time: ~15 min | Difficulty: Advanced | Reference: P07.C02.U01

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

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

Figure 24.1: DTLS Security Architecture showing the DTLS layer positioned between application protocols (CoAP) and UDP transport, with three key subsystems: security features including encryption with AES-GCM, authentication via certificates or pre-shared keys, integrity protection using HMAC, and replay protection through sequence numbers; UDP adaptations including cookie mechanism for DoS protection, explicit sequence numbers in record headers, fragmentation handling for large records, and retransmission logic for lost packets; protocol stack with application layer in orange flowing through DTLS layer in navy to UDP transport and IP network in teal.

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

Figure 24.2: TLS vs DTLS Handshake - DTLS adds cookie exchange (1 extra RTT) for DoS protection since UDP can’t verify sender IP

Key Insight: DTLS 1.3 reduces this to 2-RTT, matching TLS 1.3 performance while maintaining DoS protection.

24.3.2 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

Try It: DTLS Overhead Calculator

Adjust payload size and packet rate to see how DTLS encryption overhead compares to raw UDP.

viewof payloadBytes = Inputs.range([8, 1400], {
  value: 64,
  step: 8,
  label: "Payload size (bytes)"
})

viewof packetsPerSec = Inputs.range([1, 1000], {
  value: 10,
  step: 1,
  label: "Packets per second"
})

{
  const udpHeader = 8;          // UDP header bytes
  const ipHeader = 20;          // IPv4 header bytes
  const tlsRecordHeader = 5;    // TLS record header
  const dtlsRecordHeader = 13;  // DTLS record header (adds epoch + 6-byte sequence)
  const aeadTag = 16;           // AES-GCM authentication tag

  const rawTotal = (udpHeader + ipHeader + payloadBytes) * packetsPerSec * 8 / 1000;
  const tlsTotal = (udpHeader + ipHeader + tlsRecordHeader + payloadBytes + aeadTag) * packetsPerSec * 8 / 1000;
  const dtlsTotal = (udpHeader + ipHeader + dtlsRecordHeader + payloadBytes + aeadTag) * packetsPerSec * 8 / 1000;

  const dtlsOverheadBytes = dtlsRecordHeader + aeadTag - 0;
  const dtlsVsRawPct = (((dtlsTotal / rawTotal) - 1) * 100).toFixed(1);
  const dtlsVsTlsPct = (((dtlsTotal / tlsTotal) - 1) * 100).toFixed(1);
  const payloadEfficiency = (payloadBytes / (payloadBytes + dtlsRecordHeader + aeadTag) * 100).toFixed(1);

  return html`
  <div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid #3498DB;">
    <h5 style="margin-top:0; color:#2C3E50;">Per-Packet Overhead Analysis</h5>
    <table style="width:100%; border-collapse:collapse; font-size:0.9em;">
      <thead>
        <tr style="background:#2C3E50; color:white;">
          <th style="padding:6px 8px; text-align:left;">Protocol</th>
          <th style="padding:6px 8px; text-align:right;">Header Bytes</th>
          <th style="padding:6px 8px; text-align:right;">Total Bytes/pkt</th>
          <th style="padding:6px 8px; text-align:right;">Bandwidth (kbps)</th>
        </tr>
      </thead>
      <tbody>
        <tr style="background:#fff;">
          <td style="padding:6px 8px;">Raw UDP</td>
          <td style="padding:6px 8px; text-align:right;">${udpHeader + ipHeader}</td>
          <td style="padding:6px 8px; text-align:right;">${udpHeader + ipHeader + payloadBytes}</td>
          <td style="padding:6px 8px; text-align:right;">${rawTotal.toFixed(1)}</td>
        </tr>
        <tr style="background:#f0f8ff;">
          <td style="padding:6px 8px;">TLS over TCP</td>
          <td style="padding:6px 8px; text-align:right;">${udpHeader + ipHeader + tlsRecordHeader + aeadTag}</td>
          <td style="padding:6px 8px; text-align:right;">${udpHeader + ipHeader + tlsRecordHeader + payloadBytes + aeadTag}</td>
          <td style="padding:6px 8px; text-align:right;">${tlsTotal.toFixed(1)}</td>
        </tr>
        <tr style="background:#e8f5e9; font-weight:bold;">
          <td style="padding:6px 8px; color:#16A085;">UDP + DTLS</td>
          <td style="padding:6px 8px; text-align:right; color:#16A085;">${udpHeader + ipHeader + dtlsRecordHeader + aeadTag}</td>
          <td style="padding:6px 8px; text-align:right; color:#16A085;">${udpHeader + ipHeader + dtlsRecordHeader + payloadBytes + aeadTag}</td>
          <td style="padding:6px 8px; text-align:right; color:#16A085;">${dtlsTotal.toFixed(1)}</td>
        </tr>
      </tbody>
    </table>
    <div style="margin-top:0.75rem; display:grid; grid-template-columns:1fr 1fr 1fr; gap:0.5rem;">
      <div style="background:#16A085; color:white; padding:0.5rem; border-radius:6px; text-align:center;">
        <div style="font-size:1.4em; font-weight:bold;">${payloadEfficiency}%</div>
        <div style="font-size:0.75em;">Payload efficiency</div>
      </div>
      <div style="background:#E67E22; color:white; padding:0.5rem; border-radius:6px; text-align:center;">
        <div style="font-size:1.4em; font-weight:bold;">+${dtlsVsRawPct}%</div>
        <div style="font-size:0.75em;">DTLS vs raw UDP</div>
      </div>
      <div style="background:#3498DB; color:white; padding:0.5rem; border-radius:6px; text-align:center;">
        <div style="font-size:1.4em; font-weight:bold;">+${dtlsVsTlsPct}%</div>
        <div style="font-size:0.75em;">DTLS vs TLS extra</div>
      </div>
    </div>
    <p style="margin-top:0.75rem; font-size:0.85em; color:#555;">
      <strong>Key insight</strong>: At ${payloadBytes}-byte payloads, DTLS encryption adds ${dtlsOverheadBytes} bytes per packet
      (13-byte record header + 16-byte AEAD tag). For small CoAP payloads (8-32 bytes), this overhead is proportionally
      large but still far less than TCP's three-way handshake per connection. The overhead becomes negligible
      for payloads above ~200 bytes.
    </p>
  </div>
  `;
}

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

24.3.4 DTLS Challenges for IoT

Resource Constraints:

• Handshake cost: 6-10 messages, each requiring radio-on time (costly for battery-powered devices)
• Memory: DTLS session state requires 10-50 KB RAM (handshake buffers, crypto context, record windows)
• 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.)

DTLS 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: Use DTLS for application-specific security (e.g., CoAP), and IPsec for VPN tunnels or network-layer infrastructure protection.

24.4 Knowledge Check

Test your understanding of these networking concepts.

🏷️ Label the Diagram

💻 Code Challenge

24.5 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

Common Pitfalls

1. Using CBC Mode Cipher Suites in DTLS

TLS/DTLS cipher suites using AES-CBC (e.g., TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) are vulnerable to Lucky13 and BEAST attacks on some implementations. CBC mode also has per-record overhead for IV and padding compared to AEAD modes. Always prefer AEAD cipher suites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256. Configure cipher suite preference to exclude all CBC suites on both client and server.

2. Using RSA Key Sizes Below 2048-bit

RSA-1024 (commonly seen in legacy IoT devices) has been broken since 2010 and provides only ~80 bits of security. RSA-2048 provides ~112 bits. For new IoT deployments, use ECDSA P-256 (128-bit security, 32-byte signatures) instead of RSA-2048 (112-bit security, 256-byte signatures). ECDSA provides equivalent security with 8× smaller signatures and 5× faster key generation, critical for constrained devices with limited RAM and processing power.

3. Not Validating the Full Certificate Chain

DTLS implementations that only validate the leaf certificate (the server’s own certificate) without verifying the entire certificate chain up to a trusted root CA are vulnerable to intermediate CA impersonation. An attacker with any intermediate CA certificate can sign a fraudulent server certificate that passes leaf-only validation. Always validate the complete chain: leaf → intermediate CA(s) → root CA (trusted anchor stored on device at manufacturing time).

4. Ignoring DTLS Connection Timeouts on Constrained Networks

DTLS handshake on a constrained NB-IoT network (250 kbps, 500 ms RTT) takes 3–8 seconds for a full certificate-based handshake (6 round trips × 500 ms RTT + 3 KB certificate transmission at 250 kbps). Default DTLS handshake timeout of 1 second causes premature timeout and restart loops that never complete the handshake. Set DTLS handshake timeout to 10× the measured network RTT (minimum 5 seconds) for LPWAN networks.

24.6 What’s Next?

Continue exploring DTLS and related IoT security topics using the table below.

Chapter	Why Read It	Connection to This Chapter
DTLS Handshake Protocols	Examine the full DTLS 1.2 and 1.3 handshake message sequences, cookie exchange, and how TLS 1.3 improvements carry over to datagram transport	Builds directly on the architecture and overhead concepts introduced here
CoAP Fundamentals and Architecture	Analyze CoAP’s RESTful model, observe and map message types, confirmable vs non-confirmable, and port 5684 (CoAPs)	DTLS is the mandatory security layer for CoAP — understanding CoAP shows where DTLS is applied
TLS and Cryptographic Handshakes	Compare TLS 1.2 and TLS 1.3 handshake flows to identify which steps DTLS adapts and which it adds	DTLS inherits TLS security guarantees; contrasting the two clarifies what “adapted for UDP” means
IoT Authentication and Identity	Evaluate PSK, RPK, and certificate-based authentication schemes across different IoT device classes	The authentication mode selector in this chapter maps to these broader identity management patterns
Security Threats in IoT	Identify the attack categories that DTLS replay protection and cookie mechanisms defend against	Situates DTLS defences within the wider IoT threat landscape including replay, DoS, and MITM attacks