By 2006, TLS had already won the war for securing TCP connections. But an entire class of applications — voice, video, gaming, VPNs, and increasingly WebRTC — ran over UDP, and they were on their own. Developers who needed authenticated, encrypted datagrams either invented ad-hoc schemes (frequently broken) or tunneled UDP through TCP and paid brutal latency and head-of-line blocking costs. RFC 4347 introduced Datagram TLS (DTLS), a minimal set of surgical modifications to TLS that let it survive on a lossy, reordering, connectionless transport.

The elegant insight of Rescorla and Modadugu was: don't reinvent TLS, just patch the assumptions it makes about the underlying transport. TLS assumes three things that UDP violates:

• Reliable, in-order delivery. TLS handshake messages are a strict sequence; a lost ServerHello means the client waits forever. DTLS adds per-handshake-message sequence numbers and a retransmission timer, essentially a tiny reliability layer just for the handshake.
• Record ordering. The TLS record MAC is chained via an implicit sequence number, so any packet loss or reorder desynchronizes the MAC forever. DTLS makes the sequence number explicit in each record, and uses a sliding replay window (borrowed from IPsec) to detect duplicates while tolerating reorder.
• No fragmentation concerns. A TLS certificate message can be 4KB+; UDP packets that large will fragment or get dropped. DTLS defines its own handshake-layer fragmentation with offsets and lengths, independent of IP fragmentation.

The other novelty was the stateless cookie exchange to defeat denial-of-service amplification. In TLS-over-TCP, the three-way handshake proves the client owns its IP before the server allocates state. UDP has no such proof, so an attacker could forge source IPs and make the server generate expensive ServerHello + certificate replies aimed at victims. DTLS added an optional HelloVerifyRequest: the server returns a stateless cookie (an HMAC over the client's address), and the client must echo it back. Only then does the server allocate handshake state. QUIC's retry token mechanism is a direct descendant.

DTLS also had to give up one thing TLS took for granted: stream ciphers with implicit state. RC4-style ciphers can't tolerate packet loss, so DTLS 1.0 mandated block ciphers only, and later versions leaned hard into AEAD constructions like AES-GCM where each record is independently decryptable given the explicit sequence number as nonce input.

Why does this matter now, twenty years later? Because DTLS quietly became infrastructure:

• WebRTC uses DTLS-SRTP for every browser-to-browser call — the DTLS handshake exchanges the SRTP keys that encrypt the actual media.
• OpenVPN, Cisco AnyConnect, and most modern SSL VPNs use DTLS for the data channel because TCP-over-TCP tunneling causes catastrophic retransmit storms.
• CoAP (the constrained-device HTTP analogue) secures itself with DTLS — much of the IoT security story rests on this RFC.
• QUIC is not DTLS, but it absorbed nearly every design lesson: explicit sequence numbers, stateless retry cookies, handshake fragmentation, AEAD-only ciphers.

DTLS 1.2 (RFC 6347) and DTLS 1.3 (RFC 9147) refined the design, but the fundamental architecture — TLS minus its transport assumptions, plus five specific patches — is entirely from RFC 4347. It's a masterclass in protocol design by constrained modification rather than clean-slate invention.