Zusammenfassung
- RFC 9662 verlangt die Implementierung von ECDHE/GCM und RSA/CBC im Migrationszeitraum, bevorzugt ECDHE/GCM und setzt unterschiedliche Versionsregeln für TLS und DTLS.
- Implementiert, aktiviert, angeboten, bevorzugt und ausgehandelt sind eigenständige Zustände; keiner davon belegt die dauerhafte Zustellung eines bestimmten Ereignisses.
- Ein belastbarer Beleg verbindet Policy und Verbindungs-Epoche mit Zertifikatsprüfung, Ereignis-ID, Versand, Collector-Annahme, durable write, Index und Readback.
In der Beschaffung stand „RFC 9662 unterstützt“. Im Audit wurde daraus „moderne Suite aktiv“. Im Lagebericht erschien schließlich „sichere Logs vollständig“. Drei Sätze, drei verschiedene Behauptungen — und nur der erste war durch die Produktunterlage gedeckt.
RFC 9662 aktualisiert den kryptografischen Interoperabilitätsboden für Syslog über TLS und DTLS. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 kommt als zu bevorzugende Suite hinzu; TLS_RSA_WITH_AES_128_CBC_SHA bleibt während der Migration verpflichtend zu implementieren. Die Norm schafft gemeinsame Fähigkeiten, keine automatische Betriebswahrheit.
Fünf Zustände statt eines Compliance-Felds
Implementieren heißt, dass die Fähigkeit im Produkt vorhanden ist. Aktivieren heißt, dass lokale Policy sie zulässt. Anbieten heißt, dass ein Endpunkt sie in einer konkreten Aushandlung nennt. Bevorzugen ordnet überlappende Optionen. Aushandeln bezeichnet das tatsächlich gewählte Ergebnis einer Verbindungs-Epoche.
Ein Produkt kann eine Suite implementieren, die lokal deaktiviert ist. Ein Client kann sie anbieten, obwohl der Server sie nicht teilt. Eine bevorzugte Suite kann durch Reihenfolge, Proxy oder Altgerät nicht gewählt werden. Selbst eine moderne Aushandlung beweist nicht, dass Ereignis 7f3a den Kanal betreten hat.
Diese Felder brauchen getrennte Quellen und Zeitstempel: Produkt- und Firmwarestand, Policy-Revision, angebotene Mengen, ausgewählte Version und Suite, Resumption, early-data state und Peer-Prüfung. Ein einziges grünes „konform“ zerstört die Diagnose zwischen Fähigkeit, Konfiguration, Überschneidung und Laufzeit.
Der IANA-TLS-Registry koordiniert Kennungen und Status. Er beobachtet weder Endpunkt-Policy noch Handshake. Registry, Implementierung und laufende Verbindung sind verschiedene Realitätsebenen.
Die Versionsregel hängt am Transport
Für Syslog über TLS bleibt TLS 1.2 verpflichtend zu implementieren. TLS 1.3 sollte unterstützt und, wenn implementiert, vor älteren Versionen bevorzugt werden. Für Syslog über DTLS darf DTLS 1.0 nicht verwendet werden, DTLS 1.2 muss verwendet werden und DTLS 1.3 sollte unterstützt und bevorzugt werden.
RFC 8996 und RFC 9325 liefern den Sicherheitskontext. Ein Auditwert „1.2“ ohne Transport ist dennoch unbrauchbar. TLS 1.2 und DTLS 1.2 unterscheiden sich bei Verlust, Reihenfolge und Bestätigung; ebenso TLS 1.3 und DTLS 1.3.
Ein geschütztes Datagramm erhält dadurch keine Anwendungsquittung. Eine langlebige TLS-Verbindung beweist nicht, dass die Source Queue weiter abgearbeitet wurde. Das Transportfeld und die Verbindungs-Epoche gehören deshalb an jedes Testereignis.
Die alte Suite ist eine kontrollierte Brücke
RFC 9662 erlaubt Administratoren, RSA/CBC vorübergehend zuzulassen, wenn Syslog sonst bis zum Geräteupdate ausfiele. Zu frühes Abschalten kann genau die Telemetrie eines schwer aktualisierbaren Assets entfernen. Unbegrenzte Duldung macht aus der Brücke eine Dauerabhängigkeit.
Eine Ausnahme nennt Geräteklasse, Softwarestand, Endpoint, Peer, Transport, Suite, Kontinuitätsgrund, kompensierende Kontrollen, Owner, Ablauf und Upgrade-Test. Zusätzlich zählt sie reale Auswahlen. Nie genutzte Ausnahmen sind Kandidaten für Entfernung; ständig genutzte zeigen einen konkreten Migrationsblocker.
Kein 0-RTT bedeutet nicht genau einmal
RFC 9662 verbietet TLS-1.3-early data, weil das Syslog-Protokoll keinen Replay-Schutz bietet und 0-RTT schwächere Replay-Eigenschaften hat. Diese Regel schließt einen riskanten Pfad.
Der gewöhnliche Pfad nach dem Handshake kann Ereignisse weiterhin duplizieren oder verlieren: vor der Verschlüsselung, bei Queue-Druck, beim Reconnect, im Datagrammtransport, bei Collector-Reject, Storage-Fehler, falschem Tenant oder fehlerhaftem Index. 0-RTT-Ablehnung und End-to-End-Canary sind zwei getrennte Tests.
Peer-Authentisierung endet vor der Speicherung
RFC 5280 stellt den Rahmen für Zertifikatspfadprüfung bereit. Zusätzlich zählen erwarteter Trust Anchor, Referenzidentität und lokale Autorisierung. Eine gültige Kette kann sonst zum falschen Dienst führen.
Auch der richtige Peer ist nur eine Kanalaussage. Pro Ereignis werden stabile ID, Erzeugungs- und Queue-Zeit, Verbindungs-Epoche, Sendeversuch, Transportresultat, Annahme-ID, durable write, Indexziel, Retention-Klasse und späterer Readback benötigt.
Negative Ergebnisse bleiben differenziert: keine gemeinsame Suite, verbotene Version, Zertifikats- oder Identitätsfehler, unerlaubter Peer, early-data attempt, Verbindungsbruch, Queue overflow, Datagrammverlust, Ablehnung, Schreibfehler und Suchlücke. Nur so lässt sich Verantwortung zuweisen.
Von der Suche rückwärts belegen
Kann ein berechtigter Ermittler das erwartete Ereignis innerhalb der zugesagten Aufbewahrung finden? Der Treffer wird mit durable object und Collector-Annahme verbunden, diese mit Versand, Verbindung und Source Queue, die Verbindung mit Aushandlung, Zertifikat und Policy. So spricht kein einzelnes Control Plane für die ganze Kette.
Der kanonische Text, die XML-Quelle, die Informationsseite, Errata und Datatracker-Historie sichern die Normhistorie. Sie beobachten keine Produktionsnachricht.
Heng Lus Minimum Initial Specification hält den gemeinsamen Boden klein und lokale Entscheidungen sichtbar. Reality Layers trennt normatives Symbol und beobachtetes Ergebnis. Running-Code Primacy gibt dem System Autorität, das tatsächlich ausgehandelt, transportiert, angenommen und gespeichert hat.
RFC 9662 verbessert den gemeinsamen Kryptografieboden. Führung muss verhindern, dass die Implementierungspflicht zur unbelegten Zustellbehauptung anwächst. Erst der durchgängige Ereignisbeleg verbindet beides.
Quellen
- RFC 9662 — HTML
- RFC 9662 — kanonischer Text
- RFC 9662 — XML-Quelle
- RFC Editor — Informationen zu RFC 9662
- Errata zu RFC 9662
- IETF Datatracker — Historie von RFC 9662
- RFC 5424 — Syslog-Protokoll
- RFC 5425 — TLS-Transport für Syslog
- RFC 6012 — DTLS-Transport für Syslog
- RFC 8996 — Abkündigung von TLS 1.0 und 1.1
- RFC 9325 — Empfehlungen für TLS und DTLS
- RFC 5246 — TLS 1.2
- RFC 5280 — X.509-PKI-Profil
- RFC 6347 — DTLS 1.2
- RFC 8446 — TLS 1.3
- RFC 9147 — DTLS 1.3
- IANA — TLS-Parameter
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
- Heng Lu — Reality Layers
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

