Zusammenfassung

  • Ein TLSA-RRset wird erst durch sein DNSSEC-Ergebnis zu DANE-Evidenz: unsichere oder unbestimmte Daten sind unbrauchbar, ein bogus-Ergebnis verlangt einen Fehler.
  • Zertifikatsverwendung, Selector und Matching Type bestimmen Vergleichsobjekt und Zertifikatsregeln.
  • Eine sicher veröffentlichte Assoziation kann weiterhin unbrauchbar sein oder nicht zum tatsächlich ausgelieferten Zertifikat beziehungsweise Schlüssel passen.
  • Betriebsevidenz muss veröffentlicht, sicher, nutzbar, passend und angenommen getrennt ausweisen.

Angenommen, ein Dienstzertifikat wird um Mitternacht erfolgreich rotiert. Alle Server liefern die neue Kette, doch einige Clients haben noch eine TLSA-Assoziation zum alten öffentlichen Schlüssel im Cache. Im DNS steht ein TLSA-Eintrag, HTTPS-Monitoring ist grün und das Ticket wird geschlossen. Diese Clients brechen trotzdem ab, weil authentifizierte Assoziation und ausgelieferter Schlüssel nicht mehr übereinstimmen.

Das ist eine hypothetische Änderungsspur. Sie zeigt den Abstand zwischen Veröffentlichung und der Abstimmung aller Voraussetzungen für die Annahme.

Veröffentlichung ist nur der erste Zustand

RFC 6698 setzt TLSA aus Zertifikatsverwendung, Selector, Matching Type und Assoziationsdaten zusammen. Die Parameter bestimmen, ob eine öffentliche CA-Kette beschränkt, ein Vertrauensanker bereitgestellt oder ein vom Domaininhaber ausgestelltes Endzertifikat bezeichnet wird; ob das vollständige Zertifikat oder SubjectPublicKeyInfo verglichen wird; und ob exakte Daten, SHA-256 oder SHA-512 gelten.

Der Abfragename hängt außerdem von Dienstport, Transport und TLSA-Basisdomain ab. Wer einen anderen Dienstnamen abfragt oder bei einem unsicheren Alias stehen bleibt, kann korrekte DNS-Bytes für eine falsche Entscheidung nutzen. RFC 7671 bezieht sicher validierte CNAME-Erweiterungen in die Basisdomain ein. Ein Inventar nur mit RDATA verliert die Identität des betroffenen Dienstes.

DNSSEC entscheidet über die Nutzbarkeit

RFC 6698 macht den DNSSEC-Validierungszustand entscheidend. Ein sicheres TLSA-RRset muss verwendet werden, sofern lokale Richtlinien die konkrete Assoziation nicht verbieten. Ein bogus-Ergebnis verhindert oder beendet TLS. Ein unsicheres oder unbestimmtes RRset kann TLS nicht per TLSA authentifizieren.

„Im DNS vorhanden“ ist schwächer als „sicher validiert“, und sicher bedeutet noch nicht nutzbar. Unbekannte Werte für Verwendung, Selector oder Matching Type machen eine Assoziation unbrauchbar. Dasselbe gilt für fehlerhafte Vergleichsdaten oder nach Client-Richtlinie zu schwache Algorithmen.

Bleibt keine nutzbare Assoziation, verarbeitet die Anwendung TLS normal und ohne TLSA-Eingabe. Bleibt mindestens eine, führt sie die vorgeschriebenen Vergleiche aus und muss eine Übereinstimmung finden. Clients mit verschiedenen Fähigkeiten oder Richtlinien können dasselbe veröffentlichte RRset daher unterschiedlich behandeln.

Das ausgelieferte Zertifikat muss die Regel erfüllen

Die Zertifikatsverwendung verändert die Bedeutung der Übereinstimmung. Einige Verwendungen erhalten die PKIX-Pfadvalidierung; DANE-Verwendungen können einen DNSSEC-gestützten Vertrauensanker oder eine direkte Endentitätsbindung schaffen. Der Selector entscheidet, ob eine Erneuerung mit gleichem Schlüssel weiter passt oder jedes Zertifikatbyte zählt.

RFC 7671 ergänzt Betriebsanforderungen. DANE-TA benötigt genügend Kettenmaterial und in bestimmten Fällen das Trust-Anchor-Zertifikat vom Server. DANE-EE mit SPKI-Selector kann eine Erneuerung mit unverändertem Schlüssel überstehen, scheitert aber bei einem anderen ausgelieferten Schlüssel. Digest-Agilität wird erst nach dem Verwerfen fehlerhafter und nicht unterstützter Assoziationen angewandt.

Servergesundheit ersetzt also keine DANE-Gesundheit. Ein normaler PKIX-Client kann erfolgreich sein, während ein DANE-Client ablehnen muss. Eine opportunistische Anwendung darf ohne nutzbare sichere Assoziation eventuell unauthentifiziertes TLS verwenden; eine verpflichtende Authentifizierung darf nicht verbinden. Annahme ist eine Protokoll- und Cliententscheidung.

Zeit trennt Veröffentlichung und Annahme

TLSA-TTL, RRSIG-Gültigkeit, Cache-Alter und Rollout-Reihenfolge begrenzen die Beobachtung. RFC 7671 warnt, dass veraltete TLSA-Daten im Cache nach ungeplanten Zertifikats- oder Kettenänderungen Fehler verursachen. Lange Signaturperioden verlängern auch das Zeitfenster, in dem alte signierte DNS-Daten wiedergegeben werden können.

Eine Rotation muss alte und neue Assoziationen, autoritative Veröffentlichung, Secondaries, Validator-Caches, Dienstausbringung und Rollback koordinieren. Der neue Datensatz auf einem autoritativen Server beweist nicht, welche Bindung reale Clients sehen.