4. Verhandlung der maximalen Fragmentlänge

Ohne diese Erweiterung spezifiziert TLS eine feste maximale Klartext-Fragmentlänge von 2^14 Bytes. Es kann für eingeschränkte Clients wünschenswert sein, eine kleinere maximale Fragmentlänge aufgrund von Speicherbeschränkungen oder Bandbreitenbeschränkungen auszuhandeln.

Um kleinere maximale Fragmentlängen auszuhandeln, KÖNNEN Clients eine Erweiterung vom Typ "max_fragment_length" in das (erweiterte) Client-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung MUSS Folgendes enthalten:

enum{
    2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;

dessen Wert die gewünschte maximale Fragmentlänge ist. Die zulässigen Werte für dieses Feld sind: 2^9, 2^10, 2^11 und 2^12.

Server, die ein erweitertes Client-Hello mit einer "max_fragment_length"-Erweiterung erhalten, KÖNNEN die angeforderte maximale Fragmentlänge akzeptieren, indem sie eine Erweiterung vom Typ "max_fragment_length" in das (erweiterte) Server-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung MUSS eine MaxFragmentLength enthalten, deren Wert mit der angeforderten maximalen Fragmentlänge übereinstimmt.

Wenn ein Server eine Verhandlungsanfrage für die maximale Fragmentlänge für einen anderen Wert als die zulässigen Werte erhält, MUSS er den Handshake mit einer "illegal_parameter"-Warnung abbrechen.

Ebenso MUSS ein Client, wenn er eine Verhandlungsantwort für die maximale Fragmentlänge erhält, die von der von ihm angeforderten Länge abweicht, den Handshake ebenfalls mit einer "illegal_parameter"-Warnung abbrechen.

Sobald eine maximale Fragmentlänge außer 2^14 erfolgreich ausgehandelt wurde, MÜSSEN Client und Server sofort mit der Fragmentierung von Nachrichten (einschließlich Handshake-Nachrichten) beginnen, um sicherzustellen, dass kein Fragment größer als die ausgehandelte Länge gesendet wird. Beachten Sie, dass TLS bereits erfordert, dass Clients und Server die Fragmentierung von Handshake-Nachrichten unterstützen.

Die ausgehandelte Länge gilt für die Dauer der Sitzung einschließlich Sitzungswiederaufnahmen.

Die ausgehandelte Länge begrenzt die Eingabe, die die Datensatzschicht ohne Fragmentierung verarbeiten kann (d. h. den Maximalwert von TLSPlaintext.length; siehe [RFC5246], Abschnitt 6.2.1). Beachten Sie, dass die Ausgabe der Datensatzschicht größer sein kann. Wenn beispielsweise die ausgehandelte Länge 2^9=512 beträgt, kann für derzeit definierte Cipher-Suites (die in [RFC5246] und [RFC2712] definierten) und bei Verwendung der Null-Kompression die Ausgabe der Datensatzschicht maximal 805 Bytes betragen: 5 Bytes Header, 512 Bytes Anwendungsdaten, 256 Bytes Padding und 32 Bytes MAC. Dies bedeutet, dass in diesem Fall ein TLS-Datensatzschicht-Peer, der eine TLS-Datensatzschicht-Nachricht erhält, die größer als 805 Bytes ist, die Nachricht verwerfen und eine "record_overflow"-Warnung senden kann, ohne die Nachricht zu entschlüsseln.

Einige Anwendungen möchten möglicherweise eine höhere maximale Fragmentlänge vereinbaren. Beispielsweise können VPN-Anwendungen (Virtual Private Network) von der Verwendung größerer Fragmente profitieren. Beachten Sie, dass für UDP-Verkehr (z. B. für DTLS) es stattdessen wichtiger sein kann, kleinere Fragmentgrößen zu verwenden, um eine Fragmentierung von UDP-Datagrammen zu vermeiden.

Wenn Fragmentierung in DTLS verwendet wird, führt sie zu einem Denial-of-Service (DoS)-Risiko, wie in Abschnitt 4.1.1.1 von [RFC6347] beschrieben. Eine Serverimplementierung sollte das Risiko mindern, beispielsweise indem sie einen Wert von 1 (2^9 Bytes) nicht akzeptiert. Ein DTLS-Client, der eine Nachricht von einem authentifizierten Server erhält, die den ausgehandelten Wert überschreitet, SOLLTE eine fatale Warnung vom Typ "record_overflow" generieren. Wenn ein DTLS-Client jedoch eine Nachricht von einem nicht authentifizierten Server erhält, die den ausgehandelten Wert überschreitet, MUSS der Client die Nachricht verwerfen. Der Grund für die unterschiedlichen Regeln ist, dass ein authentifizierter Peer einfach jede Warnung senden kann, die er wählt; er muss keine große Nachricht senden. Im Gegensatz dazu ermöglicht das Erzwingen einer Antwort des Clients auf eine große Nachricht von einem nicht authentifizierten Server mehrere Angriffe.