Zusammenfassung

  • TLS erlaubte zunächst 16 KiB und später eine vom Client gewählte kleinere Fragmentgrenze für beide Richtungen. Diese Symmetrie verdeckte, dass der Empfang eines vollständig geschützten Records oft die entscheidende Speicherpflicht ist.
  • RFC 8449 schuf zwei gerichtete Empfangsangaben: Jeder Endpunkt nennt, was er empfangen kann; der Sender formt nur die zu diesem Empfänger laufenden Records entsprechend.

Senden und Empfangen kosten nicht dasselbe

Ein Sensor kann Klartext schrittweise in eine Krypto-Engine geben und Ciphertext sofort abführen. Beim Empfang darf er Klartext jedoch nicht vor der Authentisierung des vollständigen geschützten Records freigeben. Sonst könnte ein gefälschter Anfang bereits eine Anwendungshandlung auslösen, die ein später Fehler nicht zurücknimmt.

Record-Größe verteilt damit Verantwortung. Der Sender bestimmt den Inhalt einer geschützten Einheit; der Empfänger trägt den atomaren Speicherbedarf für Annahme und Prüfung. Gleiche Protokollrollen bedeuten keine gleiche Hardware. RFC 8449 änderte deshalb nicht bloß die Zahl, sondern ihre Autorität: Sie beschreibt den Empfänger.

Vom 16-KiB-Dach zum ersten kleineren Wert

TLS 1.2 zerlegt Daten in TLSPlaintext von höchstens 2^14 Byte. Eine Anwendungsnachricht kann mehrere Records belegen; mehrere gleichartige Nachrichten können zusammenfallen. Record, Nachricht, TCP-Segment und IP-Paket sind verschiedene Grenzen.

Große Records amortisieren Header und Kryptografie, erzeugen aber eine maximale Empfangspflicht. Schutz und Kompression können das Drahtobjekt weiter vergrößern. Für kleine Geräte konnte der nötige Puffer das Produkt bestimmen.

max_fragment_length, 2006 eingeführt und in RFC 6066 fortgeführt, ließ den Client 512, 1024, 2048 oder 4096 Byte wählen. Ein zustimmender Server musste denselben Wert zurückgeben; anschließend fragmentierten beide Seiten sofort auch Handshake-Nachrichten. Die Grenze galt über die Sitzung einschließlich damaliger Wiederaufnahme.

Das IoT-Profil RFC 7925 hob den Nutzen hervor: Ein beschränkter Client musste keinen 16-KiB-Eingangsbuffer mehr vorhalten. Eine interne Hardwaregrenze wurde verhandelbar.

Ein gemeinsamer Wert brachte zwei verschiedene Geräte zum Schweigen

Der alte Mechanismus bot höchstens 4096 statt 16384. Ein leistungsfähiger Client riskierte durch das Angebot unnötig kleinere Records, zusätzliche Header, Schutzarbeit und geringeren Durchsatz. Ein Server konnte zudem keine niedrigere eigene Grenze verlangen. Der Client schlug vor, und dieselbe Zahl galt in beide Richtungen.

Doch die Einschränkung liegt häufig beim Empfänger. Ein Endpunkt kann progressiv verschlüsseln und senden, aber einen großen eingehenden Record erst nach vollständigem Puffern authentisieren. Die scheinbar neutrale Symmetrie reduzierte zwei Kapazitäten auf eine und gab nur dem Initiator das Vorschlagsrecht.

record_size_limit zeigt zum Erklärenden

Der neue Wert ist die maximale geschützte Klartextmenge, die der erklärende Endpunkt in einem Record empfangen will. Sein Peer darf beim Senden zu ihm nicht darüber liegen. In Gegenrichtung darf der Erklärende größere Records senden, sofern er die Angabe des Peers und das Versionsmaximum einhält.

Eine Verbindung kann zwei Grenzen besitzen. Ein kleines Gerät fordert kleine Antworten, ohne seine Sendungen zu einem großen Dienst ebenso zu beschränken. Ein kleiner Server kann selbst sprechen. Auch unbeschränkte Endpunkte sollen die Erweiterung anbieten, damit der Peer seine Grenze wirksam mitteilen kann.

Ein TLS-Record oberhalb der erklärten Grenze führt zu fatalem record_overflow; DTLS darf ihn auch verwerfen. Werte unter 64 sind unzulässig, doch 64 ist kein Leistungsrat. Sehr kleine Records steigern Arbeit, senken Durchsatz und können Denial-of-Service-Risiken erhöhen.

Was zur Grenze zählt

Bei TLS 1.2 und früher zählt der Eingang zu Kompression und Verschlüsselung; Cipher-Padding wird anders behandelt. Bei TLS 1.3 umfasst die Grenze das ganze TLSInnerPlaintext: Inhalt, inneren Typ und Record-Padding. Padding zur Verschleierung von Längen verbraucht somit denselben Empfangsraum wie Nutzdaten.

Ungeschützte Nachrichten fallen nicht unter die Erweiterung. Bei Wiederaufnahme oder alter Renegotiation wird neu verhandelt; die Grenze folgt dem Handshake, dessen Schlüssel den Record schützen.

Kein Maß für den Pfad

Kleine Records und kleine PMTU erzeugen kleinere Einheiten, belegen aber Verschiedenes. Die Record-Grenze stammt aus dem Endpunkt und wird im Handshake fixiert. PMTU stammt aus dem Netzpfad, begrenzt Pakete und kann sich ändern. Mehrere kleine DTLS-Records können weiterhin in einem UDP-Datagramm liegen.

Auch HTTP-Antwort, Zertifikatskette oder Anwendungsnachricht werden nicht begrenzt; sie können Records überspannen. Die Erweiterung verspricht weder Bandbreite, CPU, Codeplatz, Batterie noch allgemeine Speichersicherheit. Sie begrenzt eine atomare Pflicht.

IANA führt record_size_limit (28) als Recommended und max_fragment_length (1) als nicht empfohlen. Das ist ein Interoperabilitätsstatus, kein Beweis für Produktunterstützung oder einen optimalen Wert.

Die historische Korrektur bestand darin, falsche Symmetrie aufzugeben. TLS musste die Geräte nicht gleich machen. Es musste jedem Empfänger erlauben, seine eigene Grenze zu nennen, und den Sender genau in der kostenwirksamen Richtung daran binden.

Quellen und Grenzen

Grundlagen sind RFC 4366, RFC 5246, RFC 6066, RFC 7925, RFC 8446, RFC 8449 und das IANA-Register. Sie messen keine heutige Verbreitung, Produkt-RAM oder universell beste Größe.