Zum Hauptinhalt springen

RFC 6347 - 3. Überblick über DTLS (Overview of DTLS)

3. Overview of DTLS​

Das Grundprinzip von DTLS ist „TLS über Datagrammtransport“. TLS kann in Datagrammumgebungen nicht direkt genutzt werden, weil Pakete verloren gehen oder neu sortiert werden können. TLS hat keine internen Mittel dafür; auf Datagrammtransport portierte TLS-Implementierungen versagen. DTLS ändert TLS nur minimal. Wo möglich, ist DTLS identisch zu TLS.

Unzuverlässigkeit betrifft TLS auf zwei Ebenen:

  1. TLS erlaubt keine unabhängige Entschlüsselung einzelner Records. Die Integritätsprüfung hängt von der Sequenznummer ab; fehlt Record N, schlägt die Prüfung von N+1 mit falscher Sequenz fehl. (Vor TLS 1.1 gab es kein explizites IV, daher auch Entschlüsselungsfehler.)

  2. Die TLS-Handshake-Schicht setzt zuverlässige Zustellung voraus und bricht bei Verlust.

Der Rest dieses Abschnitts beschreibt die DTLS-Lösungen.

3.1. Loss-Insensitive Messaging​

In der TLS Record Layer sind Records nicht unabhängig: Stromchiffren-Keystream bleibt zwischen Records erhalten; Anti-Replay und Umsortierungsschutz nutzen implizite Sequenznummern im MAC.

DTLS verbietet Stromchiffren und führt explizite Sequenznummern ein.

3.2. Providing Reliability for Handshake​

Der TLS-Handshake ist streng geordnet; Verlust und Umsortierung widersprechen dem. Handshake-Nachrichten können größer als ein Datagramm sein (IP-Fragmentierung). DTLS behebt beides.

3.2.1. Packet Loss​

DTLS nutzt einen einfachen Retransmission-Timer. Beim ersten Handshake:

        Client                                   Server
        ------                                   ------
        ClientHello           ------>

                                X<-- HelloVerifyRequest
                                                 (lost)

        [Timer Expires]

        ClientHello           ------>
        (retransmit)

Der Server hält ebenfalls einen Timer. Timeout und Retransmission gelten nicht für HelloVerifyRequest (würde Serverzustand erfordern). HelloVerifyRequest ist klein genug, um nicht fragmentiert zu werden.

3.2.2. Reordering​

Jede Handshake-Nachricht hat eine Sequenznummer. Passt sie zur Erwartung, wird verarbeitet; sonst gepuffert.

3.2.3. Message Size​

Handshake-Nachrichten können sehr groß sein; UDP oft unter ~1500 Bytes ohne IP-Fragmentierung. DTLS fragmentiert über mehrere Records mit fragment_offset und fragment_length.

3.3. Replay Detection​

Optional wie bei IPsec AH/ESP mit Bitmap-Fenster. Alte oder doppelte Records werden verworfen. Duplikate sind nicht immer böswillig.

Letztes Update am