Zusammenfassung

  • draft-ietf-dance-client-auth-14 wurde am 11. September eingestellt und befindet sich weiter im Working Group Last Call. Der Text ist weder RFC noch verabschiedeter Standard.
  • Revision 14 nennt vier Resultate, die kein DNSSEC-validierter TLSA-RRset sind: Validierungsfehler, nicht authentifizierte Antwort, NXDOMAIN und NODATA. Für alle gilt dieselbe Wahl: abbrechen oder den Client richtlinienabhängig als nicht authentifiziert behandeln.
  • Ein knapper Nachweis der Lookup-Entscheidung sollte Ergebnisklasse, Vertrauensweg, Richtlinienversion und spätere Autorisierung trennen. Das ist ein redaktioneller Vorschlag, keine IETF-Vorgabe.

Die Verfahrensuhr ist nicht abgelaufen

Der Datatracker datiert Revision 14 von „TLS Client Authentication via DANE TLSA records“ auf den 11. September 2026. Es ist ein aktives Dokument der DANCE-Arbeitsgruppe im Security Area. Als Ziel steht Proposed Standard, als aktueller Zustand jedoch In WG Last Call mit Nacharbeit des Document Shepherd. Beim IESG heißt es Waiting for AD Go-Ahead::AD Followup.

Das sind Ortsangaben im Prozess, keine Genehmigung. Die Historie zeigt Revision 13 am 23. Juli. Am 28. Juli wechselte der WG-Zustand von Submitted to IESG for Publication zurück zu In WG Last Call. Revision 14 wurde am 11. September angenommen. Eine RFC-Veröffentlichung ist nicht verzeichnet.

Inhaltlich ist die Änderung eng. Revision 13 behandelte den Fall einer fehlgeschlagenen DNSSEC-Validierung. Revision 14 ersetzt ihn durch jedes Ergebnis außer einem DNSSEC-validierten TLSA-RRset und zählt vier Klassen auf. Damit wird aus einem Sammelbegriff eine prüfbare Eingangstaxonomie.

Der Ausgang bleibt zweigeteilt. Der Server muss die Verbindung mit handshake_failure beenden oder darf, wenn seine Richtlinie es zulässt, den Client als nicht authentifiziert behandeln. Die Spezifikation schreibt Interoperabilität, nicht die Risikotoleranz jedes Dienstes vor.

Der Client liefert den DNS-Namen

DANE nach RFC 6698 und RFC 7671 ist vor allem für die Prüfung von Serverzertifikaten und -schlüsseln über TLSA bekannt. DANCE dreht die Perspektive zur Clientauthentifizierung.

Ein unterstützender Server kündigt die vorgeschlagene Erweiterung dane_clientid in CertificateRequest an. Der Client sendet anschließend im Certificate-Nachrichtenteil den vollständigen Owner-Namen seines TLSA-Eintrags. Der Server konstruiert keinen Namen aus Port und Transport, sondern fragt genau diesen Wert ab. Voraussetzung ist mindestens TLS 1.3 oder DTLS 1.3.

Der Server kann DNSSEC selbst bis zu einem konfigurierten Vertrauensanker, üblicherweise der Root, validieren. Alternativ darf er einem validierenden Resolver vertrauen, den er über eine sichere Verbindung erreicht, und das AD-Bit verlangen. Das Ergebnis mag gleich aussehen, doch die Beweiskette stammt von einem anderen Akteur.

Im IANA-Register der TLS ExtensionType Values war zum Recherchezeitpunkt kein Wert für dane_clientid eingetragen. Auch der Entwurf formuliert die Zuweisung in der Zukunft. Eine Kennzahl, Verbreitung oder Herstellerunterstützung lässt sich daraus nicht behaupten.

Nicht jede negative Antwort ist kaputte Validierung

Ein DNSSEC-Validierungsfehler bedeutet, dass die Daten unter der angewandten Vertrauenskette und den Regeln nicht authentifiziert werden konnten. Daraus folgt weder automatisch ein Angriff noch eine fertige Fehlerzuweisung.

Eine nicht authentifizierte Antwort aufgrund einer unsignierten Zone oder unsicheren Delegation ist etwas anderes. Dort fehlt die sichere Kette; es handelt sich nicht zwingend um signierte Daten, die eine Prüfung nicht bestanden. RFC 4033 trennt signierte und unsignierte Zonen sowie die Erwartungen aus Vertrauensankern.

NXDOMAIN sagt, dass der abgefragte Name nicht existiert. NODATA lässt den Namen bestehen, aber ohne den angeforderten TLSA-Typ. RFC 2308 bewahrt diese Unterscheidung im negativen DNS-Caching. Ein gelöschtes Geräteobjekt verlangt eine andere Prüfung als ein angelegter Name ohne veröffentlichten Schlüsselbezug.

Keine der vier Klassen beweist Bosheit. Veraltete Clientnamen, absichtlich unsichere Delegation, unvollständige Bereitstellung und gebrochene Signaturketten sind unterschiedliche mögliche Erklärungen.

Speichert der Betrieb nur handshake_failure, verschwinden diese Erklärungen. Dasselbe geschieht, wenn eine fortgesetzte Verbindung nur als Erfolg erscheint. Eine zulässige Richtlinienentscheidung kann trotzdem einen unbrauchbaren Audit-Trail erzeugen.

Erst Match, dann Berechtigung

Ein validierter TLSA-RRset ist nur der Eingang zur nächsten Stufe. Der Server muss Zertifikatsverwendung, Selektor und Matching-Typ auf das präsentierte Clientzertifikat oder den Public Key anwenden. Scheitert der Abgleich, öffnet der Entwurf erneut die Wahl zwischen Abbruch und nicht authentifizierter Behandlung.

Bei erfolgreichem Abgleich ist der Client im Sinne von DANE authentifiziert. Der Server kann trotzdem eigene Allowlisten und Autorisierungsregeln anwenden. Eine gültige Identität kann außerhalb erlaubter Domains liegen. Eine nicht authentifizierte Verbindung kann lediglich eine öffentliche Oberfläche erreichen. Verbindung, Authentifizierung und Berechtigung sind nicht dasselbe.

Darum braucht das Zustandsmodell drei getrennte Zeilen: DNS-Ergebnis, DANE-Match und Anwendungsautorisierung. Eine gemeinsame Erfolgsampel verwischt, wessen Regel entschieden hat.

Ein begrenzter Lookup-Entscheidungsnachweis

Ein vollständiger Vorfallsbericht gehört nicht in TLS. Clientnamen können Menschen, Geräte oder Rollen identifizieren; auch der Entwurf nennt Korrelationsrisiken. Sinnvoll ist ein lokal geschützter Lookup-Entscheidungsnachweis. Er ist mein redaktioneller Vorschlag, keine Pflicht von IETF, DANCE oder IANA.

Der Nachweis bindet Zeitpunkt; eine berechtigte Klarform oder einen geschützten Hash des übermittelten TLSA-Namens; Abfragetyp; eine der vier Klassen; DNSSEC-Zustand; lokale Validierung oder geschützten Resolver; Verweis auf Vertrauensanker beziehungsweise Resolverrichtlinie; Version der Serverrichtlinie und gewählten Zweig. Nur wenn erreicht, folgen Zertifikatsabgleich und abschließende Anwendungsautorisierung.

Nicht erreichte Schritte bleiben als nicht erreicht markiert. Aus NXDOMAIN wird kein erfundener Zertifikatsfehler, aus einer unsicheren Delegation kein pauschales „bogus“. Zugriff und Aufbewahrung richten sich nach der Sensibilität der Identität. Öffentliche Berichte können Klassen und Richtlinienänderungen aggregieren, ohne Gerätenamen offenzulegen.

Heng Lus Policy Mirror verlangt die Zuordnung von Akteur, Regel und Evidenz. DNS-Betreiber kontrollieren Namen und Delegation, der Client nennt die Identität, der Server wählt Validierungsweg und TLS-Richtlinie, die Anwendung vergibt Rechte. Die Minimum Initial Specification hält gemeinsame Regeln klein, damit lokale Zukunftsentscheidungen offenbleiben. Revision 14 wahrt diese Grenze; der Nachweis verhindert lediglich, dass lokale Freiheit ihre Begründung löscht.

Quellen

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Dokumenthistorie
  3. Revision 13
  4. Revision 14
  5. DANCE-Arbeitsgruppe
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — DANE-Betrieb
  8. RFC 2308 — negatives DNS-Caching
  9. RFC 4033 — DNSSEC-Einführung
  10. IANA TLS ExtensionType Values
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification