Zum Hauptinhalt springen

RFC 6347 - 4.1. Record-Schicht

4. Unterschiede zu TLS​

Wie in Abschnitt 3 erwähnt, ist DTLS bewusst TLS sehr ähnlich. Statt DTLS als neues Protokoll darzustellen, beschreiben wir es als Folge von Deltas zu TLS 1.2 [TLS12]. Wo keine Unterschiede genannt werden, entspricht DTLS [TLS12].

4.1. Record Layer​

Die DTLS-Record-Schicht ist TLS 1.2 sehr ähnlich. Die einzige Änderung ist eine explizite Sequenznummer im Record. Sie ermöglicht dem Empfänger, das TLS-MAC korrekt zu prüfen. Das DTLS-Recordformat ist unten dargestellt:

struct {
     ContentType type;
     ProtocolVersion version;
     uint16 epoch;                                    // New field
     uint48 sequence_number;                          // New field
     uint16 length;
     opaque fragment[DTLSPlaintext.length];
   } DTLSPlaintext;

type

Entspricht dem Typfeld eines TLS-1.2-Records.

version

Die verwendete Protokollversion. Dieses Dokument beschreibt DTLS 1.2 mit der Version { 254, 253 }. Der Wert 254.253 ist das Einerkomplement von DTLS 1.2. Der große Abstand zwischen TLS- und DTLS-Versionsnummern erleichtert die Unterscheidung. Künftige DTLS-Versionen auf dem Draht nehmen ab, während die eigentliche Versionsnummer steigt.

epoch

Zähler, der bei jedem Wechsel des Chiffrierzustands erhöht wird.

sequence_number

Sequenznummer dieses Records.

length

Wie das Längenfeld in TLS 1.2; darf 2^14 nicht überschreiten.

fragment

Wie das Fragmentfeld in TLS 1.2.

DTLS nutzt eine explizite Sequenznummer im Feld sequence_number. Sequenznummern werden je Epoch separat geführt, anfangs 0. Eine erneut gesendete Handshake-Nachricht aus Epoch 0 kann eine höhere Sequenznummer haben als eine zuerst gesendete Nachricht aus Epoch 1. Während des Handshakes muss darauf geachtet werden, dass Retransmissionen die richtige Epoch und Schlüsselmaterialien verwenden.

Folgen mehrere Handshakes schnell aufeinander, können mehrere Records mit gleicher Sequenznummer, aber unterschiedlichem Chiffrierzustand existieren. Das Epoch-Feld unterscheidet solche Pakete. Epoch startet bei null und wird bei jedem ChangeCipherSpec erhöht. Damit jedes Paar Sequenz/Epoch eindeutig ist, DÜRFEN Implementierungen denselben Epoch-Wert nicht innerhalb des Zweifachen der maximalen TCP-Segmentlebensdauer wiederverwenden. Praktisch sind erneute Handshakes selten.

Weil DTLS-Records umgeordnet werden können, kann ein Record aus Epoch 1 nach Beginn von Epoch 2 eintreffen. Im Allgemeinen SOLLTEN Implementierungen Pakete älterer Epochs verwerfen; bei spürbaren Verlustproblemen KÖNNEN sie Schlüsselmaterial früherer Epochs bis zur Standard-MSL von TCP [TCP] behalten. (Gemeint sind aktuelle IETF-Empfehlungen zur MSL, nicht die Abfrage der TCP-Stack-MSL.) Bis der Handshake abgeschlossen ist, MÜSSEN Implementierungen Pakete der alten Epoch akzeptieren.

Umgekehrt können mit dem neu verhandelten Kontext geschützte Records vor Abschluss des Handshakes eintreffen (z. B. Server sendet Finished und beginnt mit Daten). Implementierungen KÖNNEN puffern oder verwerfen; über zuverlässigen Transport (z. B. SCTP) SOLLTEN sie puffern und nach Handshake-Ende verarbeiten. TLS-Sendezeitregeln gelten weiter; der Empfänger behandelt Pakete wie in richtiger Reihenfolge gesendet. Insbesondere bleibt es unzulässig, vor Abschluss des ersten Handshakes Nutzdaten zu senden.

Bei erneutem Handshake auf bestehender Association ist sofortige Verarbeitung von Datenpaketen sicher, auch wenn ChangeCipherSpec oder Finished noch fehlen, wenn der Handshake die Session fortsetzt oder exakt dieselben Sicherheitsparameter wie die bestehende Association nutzt. Sonst MUSS die Implementierung auf Finished warten, um Downgrade-Angriffe zu verhindern.

Wie bei TLS MÜSSEN Implementierungen die Association aufgeben oder neu verhandeln, bevor die Sequenznummer überläuft.

Implementierungen DÜRFEN nicht zulassen, dass die Epoch überläuft; stattdessen MUSS eine neue Association gemäß Abschnitt 4.2.8 etabliert und die alte beendet werden. Wiederholte Handshakes auf demselben Kanal sind selten.

4.1.1. Transport Layer Mapping​

Jeder DTLS-Record MUSS in ein einzelnes Datagramm passen. Zur Vermeidung von IP-Fragmentierung SOLLTEN Nutzer der Record-Schicht Records so dimensionieren, dass sie in verfügbare PMTU-Schätzungen passen.

Im Gegensatz zu IPsec enthalten DTLS-Records keine Assoziations-IDs; Anwendungen multiplexen Assoziationen (bei UDP typisch über Host/Port).

Mehrere DTLS-Records können in einem Datagramm hintereinander codiert werden; das Framing bestimmt die Grenzen. Das erste Nutzlastbyte muss Record-Anfang sein; Records dürfen keine Datagrammgrenzen überschreiten.

Manche Transports (DCCP [DCCP]) haben eigene Sequenznummern; beide Nummernkreise sind gleichzeitig vorhanden. Das ist etwas ineffizient, erfüllt aber unterschiedliche Zwecke; konzeptionell ist die doppelte Nummer sinnvoll. Zukünftige Erweiterungen könnten in ressourcenbeschränkten Umgebungen nur eine Nummer nutzen.

Bei DCCP kann eine enge Überlastfenster-Retransmission von Handshake-Nachrichten verzögern und falsche Timeouts auslösen. Die wahrscheinliche Überlastfenstergrenze sollte nicht überschritten werden. [DCCPDTLS] definiert ein DTLS-auf-DCCP-Mapping.

4.1.1.1. PMTU Issues​

DTLS überlässt PMTU-Entdeckung in der Regel der Anwendung, kann PMTU aber nicht vollständig ignorieren:

  • DTLS-Framing vergrößert Datagramme und senkt die effektive PMTU aus Anwendungssicht.

  • Manchmal spricht die Anwendung nicht direkt mit dem Netz; die DTLS-Schicht kann ICMP [RFC1191] „Datagram Too Big“ oder ICMPv6 [RFC4443] „Packet Too Big“ verarbeiten.

  • Handshake-Nachrichten können die PMTU überschreiten.

Zur Behandlung der ersten beiden Punkte SOLLTE sich die Record-Schicht wie folgt verhalten:

Stehen PMTU-Schätzungen des Transports zur Verfügung, sollten sie höheren Schichten zugänglich sein:

  • DTLS über UDP: höhere Schicht SOLLTE die IP-PMTU-Schätzung abfragen können.

  • DTLS über DCCP: höhere Schicht SOLLTE die aktuelle PMTU-Schätzung abfragen können.

  • DTLS über TCP/SCTP: automatische Fragmentierung; keine PMTU-Grenze, aber höhere Schicht DARF keine Records über 2^14 Byte schreiben.

Die Record-Schicht SOLLTE die erwartete Record-Expansion durch DTLS schätzbar machen (nur Schätzung wegen Blockpadding und möglicher DTLS-Kompression).

Liegt eine Transportfehlermeldung vor (ICMP oder Sendeverweigerung wie in Abschnitt 14 von [DCCP]), MUSS die Record-Schicht die höhere Schicht informieren.

Die Record-Schicht SOLLTE PMTU-Entdeckung der höheren Schicht über [RFC1191] oder [RFC4821] nicht behindern: DF-Bit (IPv4) bzw. lokale Fragmentierung verbieten (IPv6), wenn erlaubt; PMTU-Sonden (z. B. DCCP) respektieren.

Für den Handshake: selten und kurz; PMTU-Behandlung priorisiert schnellen Abschluss. Implementierungen SOLLTEN:

  • Bei zu großer Nachricht sofort fragmentieren, falls PMTU bekannt.

  • Bei wiederholten Retransmissionen ohne Antwort und unbekannter PMTU Recordgröße verringern und Handshake fragmentieren; 2–3 Versuche vor dem Zurücknehmen sind plausibel (nicht normativ).

4.1.2. Record Payload Protection​

Wie TLS sendet DTLS geschützte Records; der Rest des Abschnitts beschreibt das Format.

4.1.2.1. MAC​

Das DTLS-MAC entspricht TLS 1.2, verwendet aber statt der impliziten TLS-Sequenznummer den 64-Bit-Wert aus Epoch und Sequenznummer in Drahtreihenfolge (gleiche Länge wie TLS-Sequenznummer).

Die MAC-Berechnung nutzt die Drahtversion, für DTLS 1.2 {254, 253}.

Bei TLS führen MAC-Fehler zum Verbindungsabbruch; bei DTLS KANN der Empfänger den fehlerhaften Record verwerfen und fortfahren, da Records nicht wie in TLS voneinander abhängen.

Implementierungen SOLLTEN ungültige oder MAC-fehlerhafte Records still verwerfen; sie KÖNNEN protokollieren. Wird bei ungültigem MAC eine Warnung gesendet, MUSS es bad_record_fatal auf fataler Stufe sein und der Verbindungszustand endet. Da Fehler nicht immer den Abbruch erzwingen, sind DTLS-Stacks stärkere Orakel; daher ist Abschnitt 6.2.3.2 von [TLS12] besonders wichtig.

4.1.2.2. Null or Standard Stream Cipher​

NULL-Chiffre wie in TLS 1.2.

Der einzige Stromchiffre in TLS 1.2 ist RC4 ohne wahlfreien Zugriff. RC4 DARF mit DTLS nicht verwendet werden.

4.1.2.3. Block Cipher​

Blockchiffre wie in TLS 1.2.

4.1.2.4. AEAD Ciphers​

TLS 1.2 führte AEAD-Suites ein; die in [ECCGCM] und [RSAGCM] definierten Suites gelten für DTLS wie für TLS 1.2.

4.1.2.5. New Cipher Suites​

Neue TLS-Suites MÜSSEN bei Registrierung angeben, ob sie für DTLS geeignet sind und welche Anpassungen nötig sind (Abschnitt 7).

4.1.2.6. Anti-Replay​

Records enthalten Sequenznummern zum Replayschutz. Die Prüfung SOLLTE mit dem gleitenden Fenster aus Abschnitt 3.4.3 von [ESP] erfolgen.

Der Empfangszähler MUSS bei Sessionstart auf null. Jeder Record MUSS auf doppelte Sequenznummern innerhalb der Session geprüft werden; diese Prüfung SOLLTE nach Sessionzuordnung zuerst erfolgen.

Duplikate werden über ein gleitendes Empfangsfenster verworfen (Implementierungsdetail lokal). Mindestfenstergröße 32 MUSS unterstützt werden; 64 ist bevorzugt und SOLLTE Standard sein. Größere Fenster SIND erlaubt (ohne Ankündigung).

Die rechte Fensterkante ist die höchste validierte Sequenznummer. Nummern links außen werden verworfen; innerhalb des Fensters Abgleich mit empfangenen Paketen (Bitmask, siehe [ESP]).

Ist der Record neu im Fenster oder rechts davon, folgt die MAC-Prüfung. Schlägt sie fehl, MUSS der Record verworfen werden. Das Fenster wird nur bei erfolgreicher MAC-Prüfung aktualisiert.

4.1.2.7. Handling Invalid Records​

Im Gegensatz zu TLS toleriert DTLS ungültige Records (Format, Länge, MAC). Ungültige Records SOLLTEN im Allgemeinen still verworfen werden, um die Association zu erhalten; Protokollierung ist optional. Werden stattdessen Warnungen gesendet, MÜSSEN sie fatal sein, um Probing zu verhindern. Über UDP ist das wegen leichter UDP-Fälschung hochgradig DoS-anfällig und wird NICHT EMPFOHLEN.

Über fälschungssicheren Transport (z. B. SCTP mit SCTP-AUTH) sind Warnungen sicherer.

Letztes Update am