Summary

  • Ein geändertes Key-Phase-Bit bestätigt erst dann ein Update, wenn das Paket mit dem nächsten Schlüssel und IV erfolgreich verarbeitet wurde.
  • Dieser Erfolg belegt die Einleitung durch den Peer in dieser Verbindung, nicht den Anlass oder die Löschung alter Schlüssel.
  • Für Ursachenfeststellungen müssen Paket-, Schlüsselgenerations-, Bestätigungs-, Auslieferungs- und Richtliniendaten zusammengeführt werden.

Während einer Softwareauslieferung meldet ein Dashboard einen Phasenwechsel. Im Störungskanal heißt er sofort Sicherheitsrotation. Die zeitliche Nähe ist ein Hinweis, doch das Bit trägt diese Erklärung nicht.

RFC 9001 §6 gibt der Key Phase eine enge Aufgabe: Sie bezeichnet die Generation der Paketschutzschlüssel eines 1-RTT-Pakets. Sie startet bei null und wechselt mit jedem Update. QUIC nutzt dafür keinen TLS-KeyUpdate-Mechanismus. Das Signal sagt, welche Schlüssel funktionieren sollten, nicht welche betriebliche Entscheidung dahinterstand.

Die Beweisgrenze setzt §6.2. Sieht der Empfänger die andere Phase, versucht er den nächsten Schlüssel und IV. Erst erfolgreiche Verarbeitung stellt fest, dass der Peer ein Update eingeleitet hat. Vor der Bestätigung dieses Pakets muss der Empfänger seine Sendeschlüssel aktualisieren; ein unter neuen Schlüsseln geschütztes ACK signalisiert Abschluss. Ein Mitschnitt mit dem Bit, aber ohne Entschlüsselungsergebnis zeigt daher nur einen scheinbaren Übergang.

Auch die Reihenfolge ist bindend. Abschnitt 6.1 verbietet Updates vor Handshake-Bestätigung sowie ein weiteres Update vor dem ACK eines Pakets der aktuellen Phase. Der Header-Schutzschlüssel ändert sich nicht. Alte Paketschutzschlüssel bleiben mindestens bis zum ersten erfolgreich mit neuen Schlüsseln geöffneten Paket erhalten und sollten wegen umsortierter Pakete noch kurz weiterbestehen.

Die Abschnitte 6.3 und 6.5 erklären, weshalb aktuelle, nächste und zeitweise vorherige Empfangsschlüssel koexistieren und Zeitsignale vermieden werden müssen. Ein gefälschtes Phasenbit kann Rechenarbeit auslösen; ein Entschlüsselungsfehler beweist weder legitimes Update noch Angriff.

Ein Vorfallsbeleg sollte Endpunktrolle, Verbindungsfingerabdruck, Paketnummer, Phase, Entschlüsselungsergebnis, Lese- und Schreibgeneration, Handshake-Zeit, auslösendes Paket, ACK unter neuem Schlüssel, Aufbewahrungsfenster, Build, Auslieferungsepoche und Richtlinienereignis verbinden. Das Protokoll belegt kryptografische Kontinuität; die Begleitdaten erklären Absicht und Ursache.