Zusammenfassung

  • Der TLSA-Owner-Name enthält Port, Transportprotokoll und Basisdomäne. Ein Treffer belegt eine Zertifikatsassoziation für dieses Dienst-Tupel und Validierungsmodell, nicht allgemeines Vertrauen in Host oder Zertifikat.
  • Reproduzierbare Evidenz umfasst den abgeleiteten Abfragenamen, DNSSEC-Status, Certificate Usage, Selector, Matching Type, Handshake-Material, Anwendungsregel und Beobachtungszeit. „DANE bestanden“ allein verliert die Zuständigkeit.

Ein zweiter Port ist eine zweite Behauptung

In einem illustrativen Test präsentiert service.example dasselbe Zertifikat auf TCP 443 und 8443. Die signierte Zone veröffentlicht einen nutzbaren TLSA-RRset nur unter _443._tcp.service.example. Für 443 kann der Client die DNSSEC-Kette prüfen und das bezeichnete Material vergleichen. Für 8443 muss er _8443._tcp.service.example abfragen; der frühere Erfolg ist nicht übertragbar.

Das Beispiel behauptet keinen Produktfehler. Es prüft eine verbreitete Abkürzung: „Dieses Zertifikat ist auf diesem Host bereits DANE-validiert.“ RFC 6698 vergibt keinen hostweiten Vertrauensstempel. Port und Transport stehen im DNS-Namen, damit benachbarte Dienste unterschiedliche Assoziationen, Verantwortliche und Wechselpläne haben können.

Speichert eine Plattform nur Hostname und Zertifikatsfingerabdruck, entfernt sie den Geltungsbereich. Bei späterer Wiederverwendung derselben Schlüssel kann sie nicht mehr zeigen, welcher Dienst ursprünglich autorisiert war.

Der Abfrageweg gehört zum Beweis

Für direktes TLS über TCP lautet die typische Form _Port._tcp.Basisdomäne. Der Port ist dezimal, das Transportlabel grenzt Protokolle ab, und die Basisdomäne stammt aus der Anwendungsnorm.

CNAME kann die Auflösung weiterleiten. SRV-basierte Anwendungen leiten den TLSA-Namen nach RFC 7673 aus der Diensterkennung ab. SMTP DANE beginnt mit MX und besitzt eigene Regeln für Basisdomäne, Referenzidentifikatoren, DNS-Fehler und Rückfall. Die endgültige Socket-Adresse reicht deshalb nicht zur Rekonstruktion.

Aufzuzeichnen sind ursprüngliches Anwendungsziel, MX/SRV/CNAME-Schritte, Namen vor und nach Expansion, Port, Transport, TLSA-Abfrage, DNSSEC-Ergebnis und die verwendete Ableitungsregel. Erst diese Kette macht das Ergebnis nachprüfbar.

Usage-Werte verkörpern verschiedene Vertrauensmodelle

PKIX-TA(0) beschränkt eine Zertifizierungsstelle und behält PKIX-Pfadvalidierung bei. PKIX-EE(1) beschränkt das Endzertifikat, ebenfalls mit gültigem PKIX-Pfad. DANE-TA(2) veröffentlicht eine Trust-Anchor-Assoziation über DNSSEC. DANE-EE(3) verbindet den Dienst direkt mit Endzertifikat oder öffentlichem Schlüssel.

Gleiche Bytes machen diese Modelle nicht austauschbar. Unter Usage 1 heilt ein Treffer kein abgelaufenes Zertifikat und keinen ungültigen Pfad. Unter Usage 3 dürfen keine fremden Web-PKI-Namensregeln erfunden werden. SMTP DANE schränkt die anwendbaren Usages für sein opportunistisches Modell zusätzlich ein.

Der vollständige Befund nennt also Usage, signierte Zone, Dienst, Client-Unterstützung und anwendungsspezifische Fehlerentscheidung.

Selector und Matching Type bestimmen das Objekt

Selector 0 wählt das vollständige DER-Zertifikat; Selector 1 den SubjectPublicKeyInfo. Ein Zertifikat kann mit demselben Schlüssel erneuert werden: Das vollständige Objekt ändert sich, der SPKI möglicherweise nicht.

Matching Type 0 vergleicht die ausgewählten Bytes, Type 1 SHA-256, Type 2 SHA-512. Ein isolierter Hexwert verrät weder das ausgewählte Objekt noch die Vergleichsoperation.

Damit ändern sich Rollout und Wiederherstellung. Die Assoziation zum vollständigen Zertifikat ist eng, verlangt aber bei jeder Erneuerung DNS-Koordination. SPKI erleichtert Erneuerungen mit demselben Schlüssel, vergrößert jedoch die Wirkung eines kompromittierten Schlüssels. Ein DANE-Trust-Anchor besitzt nochmals einen anderen Änderungsradius.

DNSSEC macht die Veröffentlichung autoritativ

Ein syntaktisch korrektes Type-52-RR ist noch keine DANE-Evidenz. Der Validator muss secure, insecure, bogus und indeterminate unterscheiden. Ein Extended DNS Error erklärt möglicherweise die Ursache, ersetzt aber nicht DS-, DNSKEY- und RRSIG-Prüfung.

Eine unsignierte Antwort darf Zertifikatsprüfung nicht abschwächen. Umgekehrt kann stiller Rückfall nach einem Fehler den Downgrade-Pfad wieder öffnen, wenn ein Anwendungsprofil einen sicheren, nutzbaren RRset als Verpflichtung behandelt. SMTP DANE erlaubt bei vorhandener nutzbarer sicherer TLSA-Assoziation keine Zustellung über einen Server, dessen Authentisierung scheitert.

DNSSEC authentisiert die Veröffentlichung unter einem Namen. Es beweist weder exklusive Kontrolle des TLS-Privatschlüssels noch korrekte Anwendungskonfiguration. DNS-Signaturpfad und TLS-Schlüssel sind getrennte Angriffs- und Verantwortungsflächen.

Nach dem Treffer beginnt die Anwendungsentscheidung

TLSA kann zeigen, dass ausgewähltes Handshake-Material eine Assoziation erfüllt. Es entscheidet nicht ALPN, HTTP-Authority, Client-Identität, Benutzerberechtigung oder Transaktionserfolg.

Ein Proxy beendet die validierte Verbindung und eröffnet eine neue Grenze zum Backend. Auch gemeinsam genutzte Endzertifikate können Substitution zwischen funktional verschiedenen Servern zulassen. RFC 7672 warnt vor diesem Teilen, sofern Ziele nicht funktional gleichwertig oder ohne Vorteil vertauschbar sind.

Die belastbare Aussage lautet: „Der präsentierte SPKI entsprach zu diesem Zeitpunkt sicherem TLSA Usage 3 für diesen Namen.“ „Die Domäne autorisierte die Aktion“ geht darüber hinaus.

Rotation ist ein beobachtbares Intervall

Eine neue Assoziation wird typischerweise vor ihrer Nutzung veröffentlicht. Alt und Neu überlappen, während Caches, Signaturen und Endpunkte konvergieren. Erst danach kann altes Material entfernt werden.

Eine Zertifikatserneuerung mit gleichem Schlüssel kann SPKI unverändert lassen; ein Schlüsselwechsel nicht. Trust-Anchor-Wechsel folgen einem anderen Ablauf als Endzertifikate. Benötigt werden Zeitpunkte für autoritative Veröffentlichung, rekursive Sichtbarkeit, Deployment, Entfernung und RRSIG-Gültigkeit. Ein grüner Resolver beweist keine globale Konvergenz.

Die Grenze wird durch Überschreitungsversuche geprüft

Präsentieren Sie dasselbe Zertifikat auf zwei Ports und veröffentlichen Sie TLSA nur für einen. Wechseln Sie Transport, CNAME, SRV und MX. Lassen Sie unter Usage 1 die Bytes passen, aber den PKIX-Pfad scheitern. Erneuern Sie erst mit gleichem, dann mit neuem Schlüssel.

Erzeugen Sie secure, insecure, bogus und indeterminate. Lassen Sie schließlich TLSA bestehen, während ALPN oder Anwendungsautorisierung scheitert. Ein korrektes System bewahrt getrennte Urteile.