Datagram Transport Layer Security

• Februar 2004: Erster Entwurf und Implementierung in OpenSSL^[1]
• 2006: RFC 4347 zur Standardisierung von DTLS 1.0.^[2]
• Januar 2012: RFC 6347 ersetzt vorherigen RFC und aktualisiert DTLS auf Version 1.2.^[3]
• April 2022: DTLS 1.3 wird in RFC 9147 veröffentlicht.^[4]

Mit Voice over IP (VoIP) und dem dort verbreiteten Signalisierungsprotokoll SIP, welches aufgrund diverser Vorteile bevorzugt über UDP übertragen wird, kam der Bedarf auf, die durch TLS gegebene Sicherheit bei SIP über TCP auch auf den Transport über UDP zu übertragen. TLS selbst ist dafür nicht geeignet, da keines der nach einem Paketverlust folgenden Pakete mehr authentifiziert werden kann.

In der Praxis wird DTLS beim ReSIProcate SIP Stack^[5], Citrix^[6] Enlightened Data Transport (ICA über UDP) und bei VPN-Protokollen wie Cisco AnyConnect eingesetzt. Im 2014 vorgestellten Netzwerkprotokoll Thread für IoT und Smart Home wird DTLS ebenfalls verwendet. Darüber hinaus kann es bei CoAP optional zur Absicherung genutzt werden. Für HART-IP über UDP (Protokollversion 2) wird DTLS zwingend vorausgesetzt.

Die Funktionsweise von DTLS entspricht weitgehend der von TLS. Um nicht durch zu starke Veränderung des ursprünglichen Protokolls eine Implikation bezüglich der Sicherheit des neuen Protokolls herbeizuführen, wurden nur an den Stellen Änderungen vorgenommen, an denen dies bei Verwendung eines nicht zuverlässigen Transportprotokolls notwendig ist. Diese Änderungen sind:

• Wiederherstellen der Zuverlässigkeit des Handshakes zu Beginn der Kommunikation, da in diesem Teil die Ankunft aller Pakete garantiert werden muss, um eine Authentifizierung und den Schlüsseltausch ermöglichen zu können. Dies geschieht dadurch, dass die Pakete nach einer bestimmten Zeit erneut gesendet werden.
• Explizite Nummerierung der einzelnen Pakete während der Übertragung. Dies geschieht bei TLS nur implizit, wodurch bei einem Paketverlust kein korrekter HMAC mehr berechnet werden kann, was eine Integritätsverletzung darstellt und wiederum zu einem Verbindungsabbruch führt.
• Eine optionale Replay-Detection für einzelne Pakete.

Falls die Anwendung einen zuverlässigen Transport benötigt, kann statt DTLS über UDP entweder TLS über TCP oder TLS über QUIC verwendet werden. QUIC gilt als Nachfolger von TCP, baut seinerseits auf UDP auf, und wird von Anwendungsprotokollen wie HTTP/3 oder DNS over QUIC (DoQ) verwendet.^[7]

• RFC 4347 – Datagram Transport Layer Security. April 2006 (veraltet, englisch).
• RFC 6347 – Datagram Transport Layer Security Version 1.2. 2012 (löst RFC 4347 ab, veraltet, englisch).
• RFC 9147 – The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. April 2022 (englisch).

1. ↑ Nagendra Modadugu und Eric Rescorla: The Design and Implementation of Datagram TLS. In: Proceedings of NDSS 2004. 2004 (stanford.edu [PDF; 194 kB]). 
2. ↑ RFC 4347 – Datagram Transport Layer Security. April 2006 (veraltet, englisch).
3. ↑ RFC 6347 – Datagram Transport Layer Security Version 1.2. 2012 (löst RFC 4347 ab, veraltet, englisch).
4. ↑ RFC 9147 – The Datagram Transport Layer Security (DTLS) Protocol Version 1.3. April 2022 (englisch).
5. ↑ reSIProcate project.
6. ↑ Configuring NetScaler Gateway to support EDT. In: citrix.com. Abgerufen am 16. Juni 2017. 
7. ↑ Monika Ermert: Internetbeschleuniger: Die IETF lässt das QUIC-Protokoll vom Stapel. In: heise online. 1. Juni 2021, abgerufen am 1. Juni 2021.