Zusammenfassung

  • draft-ietf-dance-client-auth-14 lässt einen TLS-1.3-Client den vollständigen Eigentümernamen seines TLSA-Eintrags senden; der Server fragt genau diesen Namen ab, validiert DNSSEC und gleicht den Eintrag mit Zertifikat oder Rohschlüssel ab.
  • Der Treffer beweist eine begrenzte DNS-zu-Schlüssel-Aussage. Aktuelle Zuordnung, Server-Allowlist, Anwendungsrecht und beobachtetes Ergebnis brauchen eigene Nachweise.

Der vorgeschlagene Ablauf endet nicht dort, wo die betriebliche Entscheidung beginnt. Ein Server setzt eine leere dane_clientid-Erweiterung in CertificateRequest. Der Client antwortet im Certificate mit dem vollständigen TLSA-Eigentümernamen. Der Server konstruiert keinen Namen, sondern fragt exakt diese Zeichenfolge im DNS ab.

Erhält er einen DNSSEC-validierten TLSA-RRset und passt mindestens ein Datenelement zum vorgelegten Zertifikat oder öffentlichen Schlüssel, hat die Gegenstelle Kontrolle über den passenden privaten Schlüssel gezeigt. Das ist stark, aber eng. Es sagt nicht, ob der Name noch demselben Gerät, Konto oder Unternehmen zugeordnet ist, ob der Server diese Identität zulässt oder ob die Anwendung eine konkrete Aktion erlaubt.

Offenes Verfahren und widersprüchliche Reviews

Maßgeblich ist Revision 14 vom 11. September 2026. Der Datatracker führt sie als aktiven DANCE-Working-Group-Entwurf mit Ziel Proposed Standard. Der zweite IETF Last Call läuft bis 29. September. Es gibt weder RFC-Zulassung noch Beleg für eine Implementierung.

Das Security Directorate urteilte Ready und hinterließ kleinere Hinweise. Das DNS Directorate urteilte Not ready: _service und _device erfüllten die Registrierung unterschriebener Knotennamen nach RFC 8552 nicht; auch die Darstellung und 255-Oktett-Grenze von ClientName sei unklar. Beide Bewertungen gehören zum aktuellen Stand.

Was DNSSEC und TLSA tatsächlich leisten

Clientnamen folgen keiner universellen Port-und-Transport-Konvention. Deshalb liefert der Client den vollen Namen. Der Entwurf nennt dienstspezifische, gerätespezifische und freie Formen. Die Bedeutung eines Labels entsteht jedoch durch die Stelle, die den Namensraum verwaltet, nicht durch DNSSEC.

Der Server muss bis zu einem konfigurierten Trust Anchor validieren oder einem sicher angebundenen validierenden Resolver und dessen AD-Bit vertrauen. Unsichere Delegation, unsignierte Antwort, Validierungsfehler, NXDOMAIN und NODATA ergeben keinen authentifizierten TLSA-Satz. Danach entscheidet lokale Politik über Abbruch oder unauthentifizierte Fortsetzung.

DANE-EE 3 erlaubt den direkten Schlüsselabgleich, ohne Namen im Zertifikat. DANE-TA 2 und PKIX 0/1 verlangen zusätzlich einen passenden dNSName im SAN nach RFC 7671. Rohschlüssel folgen RFC 7250. Keine Variante entscheidet über Mandant, Ressource oder Aktion.

Ein belastbarer Auditpfad trennt ClientName, DNS-Frage und TTL, Validator und Trust Anchor, TLSA-Felder, Zertifikat oder SPKI, Namenszuordnung, Konten- und Gerätestatus, Allowlist, App-Entscheidung und Ergebnis. Ein gecachter Eintrag kann gültig sein, obwohl ein Gerät neu zugeordnet wurde. Ein Handshake kann gelingen, während die Anwendung ablehnt. Eine genehmigte Aktion kann später scheitern.

TLS 1.3 verschlüsselt Certificate, doch die folgende DNS-Abfrage kann den Clientnamen offenlegen. QNAME-Minimierung nach RFC 9156 begrenzt die Sicht höherer DNS-Ebenen. Beobachtete Auflösung ist ein Datenschutzsignal, kein Beweis eines Angriffs.