Zusammenfassung

  • Revision 03 ist ein aktiver Internet-Draft, kein RFC und kein Nachweis für Implementierung, Einsatz oder Interoperabilität.
  • Jeder Endpunkt nennt die größte innere Klartextmenge, die er empfangen will; der Wert ist gerichtet und reserviert keine Ressourcen.
  • Ein syntaktisches Maximum ist weder sinnvolle Voreinstellung noch Auftrag an den Peer, Records vollständig zu füllen.
  • Größere Records verändern die AEAD-Nutzungsrechnung und müssen zusammen mit Speicher, Latenz und Anwendungsabschluss getestet werden.

Eine Obergrenze ist noch keine Konfiguration

TLS 1.3 und DTLS 1.3 begrenzen den inneren Klartext üblicherweise auf 2^14 + 1 Oktette. large_record_size_limit soll Werte von 64 bis 2^30 - 256 ermöglichen. Der obere Wert beschreibt, was das vorgeschlagene Format ausdrücken kann. Er beschreibt nicht, was ein bestimmter Dienst unter Last sicher verarbeiten sollte.

Produktionswerte müssen aus Arbeitslast, Allokator, Scheduler, Parallelität und Überlastverhalten folgen. Ein Laborerfolg mit einem maximalen Record beweist nicht, dass viele langsame Verbindungen gleichzeitig unvollständige Records halten können. Ebenso wenig beweist eine erfolgreiche Aushandlung, dass Speicher im Voraus reserviert wurde.

Eine belastbare Entscheidung beginnt deshalb deutlich unter dem Protokollmaximum. Sie erhöht Werte schrittweise, misst Ressourcen und hält einen Rückweg offen. Die Syntax setzt den äußeren Zaun; die Plattform bestimmt den nutzbaren Bereich.

Die Zusage gilt nur in eine Richtung

Die Erweiterung handelt keinen gemeinsamen Wert aus. Der Client erklärt, wie viel er vom Server empfangen kann; der Server erklärt dasselbe für die Gegenrichtung. Beide Zahlen dürfen verschieden sein.

Ein Endpunkt kann einen Record senden, der größer ist als sein eigener angekündigter Empfangswert, solange er unter dem Wert des Peers bleibt. Wer beide Werte in einer Spalte zusammenführt, verliert den Verpflichteten. Legitime Sendungen erscheinen dann als Verstoß oder echte Überschreitungen verschwinden hinter dem größeren Gegenrichtungswert.

Telemetrie braucht Verbindung, Endpunktrolle, Richtung, lokale Richtlinie, gesendete und empfangene Ankündigung sowie tatsächliche authentifizierte Länge. Richtung ist Teil der Aussage, nicht bloß ein Filter im Dashboard.

Der Wert ist außerdem ein Dach, kein Ziel. Der Sender kann kleinere Records wählen, um früher zu authentifizieren, interaktive Daten auszuliefern, Speicher zu schonen oder auf Verlust und Stau zu reagieren.

Speicher wird außerhalb des Handshakes regiert

Eine Implementierung kann Pools, Streaming, globale Quoten oder Backpressure verwenden. Nichts in der Erweiterung verpflichtet sie, für jede Verbindung einen zusammenhängenden Puffer in Höhe des angekündigten Wertes bereitzuhalten.

Das Kapazitätsmodell muss Chiffretext, AEAD-Zustand, zurückgehaltenen Klartext, Padding, Reassembly, Warteschlangen und Abbruch berücksichtigen. Besonders wichtig sind viele gleichzeitig angefangene, langsam vervollständigte Records. Ein Angreifer oder nur ein ungünstiger Lastverlauf kann Lebensdauer und Zahl dieser Zustände bestimmen.

Der Nachweis lautet daher nicht „Maximal-Record empfangen“, sondern zeigt eine Kurve: Speicherbelegung, Authentifizierungswarteschlange, Teil-Records pro Verbindung, Abbruchkosten und Dienstverhalten bei der festgelegten Parallelität.

Auch unsichtbare Bytes zählen

Der Grenzwert gilt für den inneren TLS-1.3-Klartext. Dieser enthält den Inhaltstyp und kann Padding enthalten. Eine Anwendungsnutzlast knapp unter dem Dach kann durch Padding zu groß werden.

Datenschutz-, Anwendungs- und TLS-Verantwortliche müssen daher dieselbe Einheit verwenden. Protokolliert werden Länge, Richtlinienversion und Richtung, nicht sensible Inhalte. Anwendungsbytes, innerer Klartext, Chiffretext und Netzwerkbytes dürfen nicht als austauschbare Größe erscheinen.

Werte unter 64 oder über 2^30 - 256 führen zu einem fatalen illegal_parameter. Dieser Beleg sagt, dass die Aushandlung ungültig war. Er erlaubt weder stilles Runden noch eine erfundene Ersatzgrenze.

Überschreitung hat zwei Fehlerformen

Empfängt TLS einen Record oberhalb der geltenden Grenze, verlangt der Entwurf ein fatales record_overflow; die geordnete Verbindung endet. Bei langlebigen Sessions kann eine Richtliniendifferenz damit unmittelbar Verfügbarkeit kosten.

Bei DTLS soll ein zu großes Datagramm verworfen werden und keinen fatalen Alert auslösen. Verlust gehört zum Datagrammmodell, und eine zerstörerische Antwort auf möglicherweise bösartige Eingaben kann Denial-of-Service erleichtern.

Ein gemeinsamer Alarm „jede Überschreitung muss die Session beenden“ wäre falsch. Beobachtung muss Protokoll, Epoche, Richtung, Länge, Grenze, Aktion und Alert unterscheiden. Stille bei DTLS kann korrekt sein; dieselbe Stille bei TLS verlangt Prüfung.

Record, Paket und Nachricht bleiben getrennt

Der Entwurf will wiederholte Record-Header und AEAD-Overhead senken. In manchen DTLS-Anwendungen mit großen Nachrichten kann er Fragmentierung oberhalb der Record-Schicht vermeiden. Daraus folgt keine universelle Gleichheit von Record und Anwendungsnachricht.

Eine Nachricht kann mehrere Records belegen, ein Record kann Daten enthalten, die die obere Schicht trennt, und der Transport kann einen großen TLS-Record in viele Segmente zerlegen. Weniger Records bedeuten nicht automatisch weniger Pakete, weniger Wiederholung oder atomare Auslieferung.

Die Beweiskette führt von der Ankündigung über gewählte Größe und erfolgreiche Authentifizierung zu Reassembly, Parser, Autorisierung und Ergebnis. Für jede Stufe braucht es einen eigenen Nenner. Ausgehandelte Erlaubnis darf nicht als ausgelieferte Anwendungstransaktion gezählt werden.

Headerersparnis kann Wartezeit erzeugen

Vertrauenswürdiger Klartext steht der Anwendung im Allgemeinen erst nach erfolgreicher Authentifizierung des gesamten Records zur Verfügung. Größere Einheiten können die Zeit vom ersten Byte bis zu diesem Punkt verlängern. Unter Verlust können sie länger Warteschlangen belegen oder mehr Wiederholungsarbeit auslösen.

Der Entwurf verspricht keine geringere Latenz. Zu messen sind Größenverteilung, Zeit bis Authentifizierung, Queue-Aufenthalt, Speicher je Verbindung, gleichzeitige Teil-Records und Anwendungsabschluss. Ein besserer Mittelwert für Bulk kann mit schlechteren Perzentilen für Interaktion koexistieren.

Hohe erlaubte Werte und kleine tatsächlich gesendete Records sind kein Widerspruch. Sie können eine bewusste Dienstpolitik darstellen.

Das Schlüsselbudget wächst nicht in Records allein

AEAD-Grenzen hängen von Konstruktion, Aufrufen und Datenmenge ab. Bei AES-GCM ist die Zahl der Blöcke besonders relevant. Der Entwurf passt die Rechnung für größere Records mit einem Faktor rund um LargeRecordSizeLimit / 2^14 und, wo nötig, genauer Blockbetrachtung an.

Bleibt ein historischer KeyUpdate-Schwellenwert in reinen Recordzahlen unverändert, während die Bytes pro Record steigen, misst die Kontrolle nicht mehr denselben Verbrauch. Erforderlich sind Cipher Suite, Richtung, Schlüsselepoche, authentifizierte Bytes oder konservative Blöcke, Recordzahl und Rotation.

Das ist kein Urteil, große Records seien unsicher. Es ist die Forderung, den Sicherheitsbeleg an die erlaubte Hülle anzupassen. Der Handshake bescheinigt keine Schlüssel-Lebensdauerpolitik.

Stufen und Rückbau sind ein gemeinsamer Plan

Ein Rollout wählt Werte nach Endpunkt- und Lastklasse. Er prüft asymmetrische Grenzen, langsame Sender, Verlust, maximales Padding, viele Teil-Records und Nachrichten auf beiden Seiten einer Recordgrenze. TLS und DTLS werden getrennt bewertet.

Eine abgesenkte Konfiguration ändert neue Aushandlungen, nicht rückwirkend bestehende Verbindungen. Rückbau braucht Draining, Kompatibilität, angepasste Schlüsselpolitik und eine Unterscheidung zwischen fehlender Peer-Unterstützung und lokaler Deaktivierung.

Das Entscheidungsbild zeigt daher mehrere Quittungen: Einstellung, gerichtete Ankündigung, tatsächliche Größe, Authentifizierung, Ressourcen, Kryptobudget, Reassembly und Anwendungsergebnis. Nur so bleibt eine Headerersparnis eine überprüfbare Chance statt eines unbelegten Versprechens.

Quellen und Grenzen

Das eingefrorene Paket umfasst Revision 03 mit offizieller Akte, Historie und Referenzen; die TLS-Arbeitsgruppe; TLS 1.3 und den Überarbeitungsentwurf; DTLS 1.3; die bestehende Record-Size-Erweiterung; DTLS/SCTP; MLS; QUIC; AEAD-Anforderungen; AES-GCM-Suites und das IANA-TLS-Register.

Diese Quellen belegen Protokoll- und Registertext. Sie belegen keine ausgelieferte Implementierung, Übernahme, Interoperabilität, Leistungssteigerung, Speicherersparnis, Latenzverbesserung, Störung, Attacke oder Anwendungswirkung. Der Einstiegsfall ist konstruiert.

Quellen