Zusammenfassung

  • Die IESG genehmigte am 3. September 2026 Version 25 der TLS/DTLS 1.3 Profiles for the Internet of Things als Proposed Standard. Eine endgültige RFC-Nummer nannte die Mitteilung noch nicht.
  • Das Dokument ergänzt RFC 7925 und ändert dort gezielt das X.509-Zertifikatsprofil und die Anforderungen an Cipher Suites. TLS/DTLS 1.2 bleibt für langlebige Altanlagen relevant.
  • Der Entwurf zieht selbst die entscheidende Grenze: Protokollkompatibilität ist notwendig, reicht für Interoperabilität bei Authentisierung und Autorisierung aber nicht aus.
  • Zertifikate, rohe öffentliche Schlüssel und externe PSKs verteilen Identitäts-, Bereitstellungs- und Lebenszykluspflichten unterschiedlich. Kein erfolgreicher Handshake erteilt allein eine betriebliche Erlaubnis.
  • Ein versionierter Nachweis sollte Berechtigungsregel, erwarteten Peer, Credential-Modus, Trust Anchor, Sitzungsalter, Neuauthentisierung, Fehlerreaktion und Rücknahme verbinden, ohne Schlüssel oder sensible Gerätedaten offenzulegen.

Ein belastbarer gemeinsamer Sockel

Die Protocol Action ist eine echte Standardisierungsentscheidung. Das Dokument stammt aus der Working Group Using TLS in Applications, fand breite Unterstützung und wurde für den Standards Track genehmigt. Es ordnet für eingeschränkte Geräte die unterstützten Anmeldeformen, Erweiterungen, Alarmbehandlung, Sitzungswiederaufnahme, Forward Secrecy, Timer, Datensatzgrößen, Zertifikate und Cipher Suites.

Dieser Sockel ist notwendig, weil „TLS 1.3 unterstützt“ in einem knappen Gerät wenig aussagt. Zwei Implementierungen können jeweils Optionen entfernen und dennoch unterschiedliche Annahmen über Pflicht-Erweiterungen, Zertifikatfelder oder PSK-Verwendung treffen. Das Profil schafft eine prüfbare gemeinsame Ausgangslage.

Seine Wirkung endet nicht zufällig vor der Autorisierung. Version 25 erklärt ausdrücklich, dass TLS-Kompatibilität nur die Grundlage bildet. Die Kryptografie kann eine Schlüsselverfügung im ausgehandelten Kontext authentisieren. Sie entscheidet nicht, ob dieser Schlüssel zum erwarteten Gerät gehört, welche Rolle es besitzt und welchen Befehl es ausführen darf.

Auch der Dokumentstatus bleibt gestuft. Die IESG hat einen Proposed Standard genehmigt. Redaktion und endgültige RFC-Nummer folgen. Daraus wird weder ein Internet Standard noch eine Produktzertifizierung. Eine institutionelle Freigabe des Textes ist nicht der Nachweis, dass eine benannte Firmware ihn implementiert.

RFC 7925 wird nur begrenzt aktualisiert. Industrielle Geräte, Zertifizierungen und Wartungsprozesse haben lange Laufzeiten. Das ältere TLS/DTLS-1.2-Profil bleibt deshalb relevant. Ein gemischter Bestand ist kein automatischer Fehler; unklar wäre ein Bestand, dessen Geräte keiner dokumentierten Profilgeneration zugeordnet sind.

Die Berechtigung steckt nicht im Credential

Das Profil lässt drei Hauptwege zu. X.509-Zertifikate, rohe öffentliche Schlüssel und externe Pre-Shared Keys haben verschiedene Kosten und Sicherheitsmerkmale. Die Spezifikation schreibt keinen einzigen Weg für alle Einsätze vor.

Ein Zertifikat bindet einen öffentlichen Schlüssel unter einer ausstellenden Kette an einen Bezeichner. Es bindet ihn noch nicht an eine lokale Aufgabe. Die Unterscheidung zwischen dem meist beim Hersteller gesetzten IDevID und dem betrieblichen LDevID zeigt den Übergang: Die Anfangsidentität kann das Onboarding ermöglichen; der Eigentümer oder Betreiber vergibt die Identität für den konkreten Betriebsbereich. Bequemlichkeit darf aus dem Bootstrap-Credential keine dauerhafte Vollmacht machen.

Ein roher öffentlicher Schlüssel spart Zertifikatsdaten, benötigt aber eine externe Bindung an den erwarteten Peer. Wird SNI wegen eines fest hinterlegten Schlüssels, Zertifikats, Endpunkts oder PSK-Bezeichners ausgelassen, muss eine andere Bindung bestehen. Sonst wird der richtige Schlüssel geprüft und der falschen Gegenstelle zugerechnet.

Beim externen PSK liegen Identität, Entropie, Geltungsbereich, Versionsabgrenzung und Wechsel außerhalb des Handshakes. Das Profil verlangt nach Möglichkeit (EC)DHE für Forward Secrecy. PSK-only ist nur zulässig, wenn der Verlust dieser Eigenschaft ausdrücklich für die konkrete Installation akzeptiert wurde. Diese Ausnahme braucht Verantwortlichen, Umfang und Ablaufdatum.

SNI kann Serverkontext und Zertifikat auswählen, ALPN den Anwendungsweg. Autorisierung bleibt laut Dokument eine Funktion aus authentisiertem Credential und lokaler Policy. Ein ausgehandeltes Protokoll ist kein Recht, dessen Operationen auszuführen.

Wenn das Gerät nicht widerruft, muss der Betrieb handeln

Viele eingeschränkte Geräte können im Handshake weder OCSP noch CRLs prüfen. Version 25 setzt üblicherweise auf kurzlebige Betriebszertifikate, automatisiertes Onboarding und Management. Der Widerruf verschwindet nicht. Er wird in die Verwaltung und die Anwendung verlagert.

Eine neue Zertifikatsdatei beendet jedoch keine alte Sitzung. TLS verpflichtet eine bestehende Verbindung nicht zur dauernden Gültigkeitsprüfung. Falls fortlaufende Validierung erforderlich ist, muss die Anwendung neu authentisieren oder die Verbindung trennen und wieder aufbauen. Wechselseitige Authentisierung nach dem Handshake verlangt außerdem Unterstützung im Anwendungsprotokoll.

Darum sind „Credential ersetzt“ und „alte Berechtigung beendet“ zwei getrennte Zustände. Zwischen ihnen liegen Sitzungen, Tickets und Geräte, die noch keinen Kontakt hatten. Ein Betriebsnachweis muss dieses Intervall sichtbar machen.

Noch länger wirkt der Trust Anchor. Ein Gerät kann mehrere CA-Wechsel, Herstellerübergänge, Algorithmusmigrationen oder Vorfälle erleben. Firmware- und Zertifikatsmanagement kann einen neuen Anchor verteilen. Es beweist noch nicht, dass er angekommen, installiert, ausgewählt und der alte entfernt wurde. Jede Stufe braucht einen eigenen Status.

Weniger Bytes bedeuten mehr Entscheidungen

Im Minimalbeispiel der Version 25 beanspruchen zwei kleine ECC-Zertifikate bei gegenseitiger TLS-1.3-Authentisierung ohne untergeordnete CA rund 40 Prozent der Handshake-Nutzlast. Kürzere Ketten, Kompression, Cache und Resumption sparen Übertragung und Rechenleistung.

Die Einsparung ist nicht kostenlos. Anzahl, Lebensdauer und Wiederverwendung von Tickets verschieben Serverzustand, Replay-Risiko und Privatsphäre. Externe Zertifikatsbeschaffung schafft DNS- oder Verzeichnisabhängigkeiten und kann stabile Kennungen offenbaren. Ein Cache braucht eine Invalidierungsregel. Jedes gesparte Funkpaket kann eine neue Freshness-Pflicht an anderer Stelle erzeugen.

Bei 0-RTT zieht das Dokument eine harte Linie. Ein Anwendungsprotokoll darf frühe Daten nur mit einem eigenen Profil nutzen, das sichere Nachrichten und den Rückfall auf 1-RTT definiert. Für CoAP und MQTT existierte nach Version 25 kein solches Profil; dieses Dokument schaltet 0-RTT für sie nicht frei. Fähigkeit ist nicht Erlaubnis.

Unbeaufsichtigte Geräte brauchen ebenso eine Fehlerpolitik oberhalb der Bibliothek. Die Anwendung entscheidet, welcher Alert einen neuen Versuch, einen anderen Endpunkt, ein anderes Credential oder einen sicheren Betriebszustand auslöst. TLS meldet den Zustand; der Betreiber verantwortet die Wirkung.

Ein Nachweis an der Autorisierungsgrenze

Der Nachweis beginnt mit Profilversion und Build. Hinzu kommen Credential-Modus und stabile Referenz, erwartete Peer-Identität und Bindungsmethode, Anwendungsprotokoll und Rolle, Policy-Version sowie die erlaubte oder verweigerte Aktionsklasse.

Der Lebenszyklusblock enthält Anchor-Generation, Zertifikats- oder PSK-Generation, Bereitstellungskanal, beobachtete Aktivierung, Ablauf und Ersatz. Der Sitzungsblock trennt vollen und wiederaufgenommenen Handshake, nennt Ticket-Generation, Beginn, letzte Neuauthentisierung und Höchstalter. Eine Forward-Secrecy-Ausnahme wird mit Besitzer und Ende protokolliert.

Der Sicherheitsblock verbindet wesentliche Fehler mit Wiederholung, Ausweichweg, eingeschränktem Modus oder sicherem Stopp. 0-RTT steht auf aus oder wird nach einem künftigen Profil auf bezeichnete Nachrichtentypen und Anti-Replay-Zustand begrenzt. Korrekturen werden angehängt, nicht überschrieben, weil alte Sitzungen nach alten Regeln entstanden.

Privatschlüssel, komplette Zertifikate, interne Namen und genaue Topologie gehören nicht in eine öffentliche Fassung. Aggregierte Kohorten, Versionen, Zeitpunkte, Ergebnisse und Ausnahmen reichen, um die Behauptung prüfbar zu machen.

Heng Lus Minimum-Specification-Gedanke ist hier eine begrenzte redaktionelle Leitlinie. Gemeinsame Regeln sollen klein, deterministisch und lokal prüfbar bleiben. Er beweist nichts über eine Installation. Er verhindert sowohl eine universelle IETF-Berechtigungspolitik als auch eine unsichtbare lokale Entscheidung, die sich mit dem Namen des Standards schmückt.

Was nicht beschlossen wurde

Keine Quelle belegt die Konformität eines bestimmten Produkts, eine migrierte Flotte oder einen Vorfall. Die IESG hat weder CA noch PSK-Modell, Berechtigungstabelle oder sicheren Zustand eines Betreibers ausgewählt.

Das Profil ist auch nicht quantenresistent. Seine normativen Cipher Suites beruhen auf klassischer Kryptografie; der PQC-Abschnitt ist informativ und fügt keine Pflicht hinzu. Lange Produktlebensdauer macht Planung notwendig, nicht Migration abgeschlossen.

Schließlich behauptet der Text nicht, jedes eingeschränkte Gerät könne niemals OCSP oder CRLs nutzen. Er beschreibt einen verbreiteten Ressourcenfall und empfiehlt eine Abwägung. Fähigere Plattformen können anders entscheiden.

Gerade diese Grenzen machen die Genehmigung nützlich. Die IETF verringert vermeidbare Inkompatibilität. Wer ein Gerät zulässt, behält die Autorität – und die Pflicht, ihren Zustand zu belegen.

Quellen

  1. IESG — Protocol Action zum IoT-Profil
  2. IETF — genehmigte Version 25
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — TLS/DTLS-Profile für IoT
  6. RFC 5280 — X.509-PKI-Profil
  7. RFC 9257 — externe PSKs
  8. RFC 9258 — Import externer PSKs
  9. RFC 9019 — Firmware-Updates für IoT
  10. RFC 8995 — BRSKI
  11. RFC 9525 — Dienstidentität in TLS
  12. RFC 9325 — sicherer Einsatz von TLS und DTLS
  13. Heng Lu — Minimum Initial Specification