DTLS Handshake Visualizer

Explore how Datagram TLS secures UDP-based IoT protocols such as CoAP

animation
security
dtls
coap
tls
handshake
interactive
A defensive DTLS handshake animation with message flights, cookie verification, retransmission behavior, epoch and sequence tracking, authentication profiles, and technical accuracy notes.
Animation Security DTLS CoAP

DTLS Handshake Visualizer

Watch how DTLS protects a UDP-based IoT session without pretending UDP is reliable. This teaching model focuses on a DTLS 1.2-style CoAP handshake: cookie verification, message flights, retransmission, epoch changes, and replay protection.

-- Auth profile
-- Current flight
-- Record epoch
-- Next review action
1. Start Client sends an initial hello over UDP.
2. Cookie Server avoids allocating state until the client proves reachability.
3. Parameters Server sends version, cipher, and authentication information.
4. Keys Peers derive keys and switch to protected records.
5. Verify Finished messages confirm the transcript and application data can flow.

Constrained CoAP PSK Handshake

--

--

--

DTLS Quick Reference

Why DTLS exists

  • TLS assumes reliable ordered transport.
  • CoAP commonly runs over UDP, so DTLS adds datagram-aware reliability.
  • The security goal is still confidentiality, integrity, authentication, and replay protection.

Cookie exchange

  • ClientHello can be answered with HelloVerifyRequest in DTLS 1.2.
  • The client retries with the cookie to prove it can receive at that address.
  • The server avoids expensive state before verification.

Flights and timers

  • Handshake messages are grouped into flights.
  • If the next expected flight is not received, the previous flight can be retransmitted.
  • Receivers use sequence information to reorder and detect duplicates.

Epoch and sequence

  • Epoch identifies the active cipher state.
  • Sequence numbers support anti-replay checks.
  • Record protection starts only after keys are established.
Technical Accuracy Notes

Version scope

The visible flight sequence is DTLS 1.2-style because it makes the cookie, ChangeCipherSpec, and flight retransmission concepts explicit. DTLS 1.3 changes message names and removes the same visible CCS pattern.

PSK nuance

A plain PSK profile is compact but does not automatically provide forward secrecy. ECDHE-PSK adds ephemeral key exchange at extra cost.

Cookie limits

Cookie verification reduces spoofed-source resource exhaustion. It is not a replacement for rate limits, authentication, access control, or correct implementation.

Size estimates

The byte and fragment values are teaching estimates, not library benchmarks. Real sizes depend on cipher suite, certificates, extensions, compression, MTU, and implementation choices.

Practice Prompts

Cookie effect

Turn cookie exchange off, then raise loss. What security and resource risk appears in the diagnosis?

Certificate overhead

Select X.509 certificate and increase MTU pressure. Why does fragmentation risk rise?

Forward secrecy

Compare PSK and ECDHE-PSK. What changes, and what extra cost does the model show?

Resumption

Enable resumption. Which metrics improve, and why is the first full handshake still important?

DTLS Flight Pattern

Focus on flight grouping and retransmission behavior.

DTLS vs TLS

Compare datagram and stream security models.

TLS Handshake

Review the stream-oriented handshake foundation.

CoAP Messages

Inspect the UDP application protocol DTLS often protects.