RFC 6347 - 1. Einleitung (Introduction)

1. Introduction

TLS [TLS] ist das am weitesten verbreitete Protokoll zum Schutz von Netzwerkverkehr. Es schützt Web-Traffic und E-Mail-Protokolle wie IMAP [IMAP] und POP [POP]. Der Hauptvorteil von TLS ist ein transparenter, verbindungsorientierter Kanal. Anwendungsprotokolle lassen sich leicht absichern, indem TLS zwischen Anwendungs- und Transportschicht eingefügt wird. TLS erfordert jedoch einen zuverlässigen Transport, typischerweise TCP [TCP], und kann daher unzuverlässigen Datagrammverkehr nicht schützen.

Immer mehr Anwendungsprotokolle nutzen UDP, insbes SIP [SIP] und Onlinespiele. (SIP kann TCP und UDP nutzen; UDP ist mitunter bevorzugt.) Entwickler stehen vor unbefriedigenden Optionen: IPsec [RFC4301], das nach [WHYIPSEC] nur für manche Anwendungen passt, oder maßgeschneiderte Anwendungssicherheit mit hohem Designaufwand im Vergleich zu TLS.

Oft wäre TLS die beste Wahl; Datagrammsemantik schließt TLS jedoch aus. Dieses Memo beschreibt Datagram Transport Layer Security (DTLS), absichtlich TLS so ähnlich wie möglich, um neue kryptographische Erfindungen zu minimieren und Code sowie Infrastruktur wiederzuverwenden.

DTLS 1.0 [DTLS1] war als Delta zu [TLS11] definiert. Dieses Dokument führt DTLS 1.2 ein, definiert als Deltas zu TLS 1.2 [TLS12]. Es gibt kein DTLS 1.1; die Versionsnummer wurde übersprungen, um mit TLS übereinzustimmen. Unklare Punkte von DTLS 1.0 werden geklärt.

Implementierungen mit DTLS 1.2 und 1.0 können mit reinen DTLS-1.0-Peers (natürlich mit DTLS 1.0) interoperieren, analog zu TLS 1.2 mit älteren TLS-Versionen (Anhang E.1 in [TLS12]), außer dass es kein DTLS für SSLv2/v3 gibt.

1.1. Requirements Terminology

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" sind wie in RFC 2119 [REQ] zu interpretieren.