Zusammenfassung

  • Erst eine gültige TLSA-Authentifizierungskette, die zur Zertifikatskette passt und DANE erfolgreich abschließt, kann für einen SNI-Namen und Port eine nichtnullige ExtSupportLifetime begründen. Der TLSA-TTL und der Pin messen unterschiedliche Pflichten.
  • Authentisierte TLSA-Nichtexistenz, ein Beleg für unsichere Delegation oder ein verifizierter Übergang auf null können den Pin löschen. Eine fehlende Erweiterung bei aktivem Pin ist kein negativer Beleg und kann den Verbindungsabbruch erzwingen.

Der Resolver vor seiner ersten vertrauenswürdigen Antwort

Ein DNS-over-TLS-Client möchte seinen Resolver mit DANE authentisieren. Dafür braucht er dessen TLSA-RRset samt DNSSEC-Pfad. Die naheliegende DNS-Abfrage würde jedoch gerade über den Resolver laufen, dessen Identität noch offen ist. Die experimentelle dnssec_chain-Erweiterung aus RFC 9102 transportiert deshalb die benötigten Resource Records und Signaturen innerhalb des TLS-Handshakes.

Die Serverantwort enthält die aktuelle Kette und eine 16-Bit-Zahl in Stunden: ExtSupportLifetime. Die Kette sagt, ob der TLSA-Beleg für den SNI-Namen und Port jetzt gültig ist und zur präsentierten Zertifikatskette passt. Die Zahl sagt, wie lange der Server oder sein Cluster die Erweiterung weiterhin anbieten will. Beides wird gemeinsam übermittelt, aber nicht gemeinsam gültig.

Shumon Huque verfasste RFC 9102 zusammen mit Viktor Dukhovni, Willem Toorop, Paul Wouters und Melinda Shore; die ursprüngliche Idee schreibt das Dokument Adam Langley zu. Huques IETF-Profil und seine öffentliche Biografie nennen DNS-Infrastruktur, Networking und Sicherheitsprotokolle als Arbeitsfelder, heute bei Salesforce und zuvor bei Verisign sowie der University of Pennsylvania. Diese Spur belegt eine Mitwirkung, keine Alleinautorität über DANE, DNSSEC, TLS oder den Experimental RFC.

Ein sichtbarer Wert erzeugt noch keinen Zustand

Ein Client darf einen non-zero Wert nur übernehmen, wenn die Erweiterung eine gültige TLSA-Authentifizierungskette enthält, diese die Serverzertifikatskette tatsächlich authentisiert und der DANE-Handshake vollständig gelingt. Ein syntaktisch korrektes Feld, eine PKIX-Akzeptanz oder ungeprüfte DNS-Daten reichen nicht. So kann kein Angreifer durch bloße Einspeisung eine langlebige Verpflichtung im Client erzeugen.

Auch der Schlüssel des Zustands ist begrenzt. Der Request trägt den TCP-Port; der Name stammt aus SNI. Beim Aufbau der eingebetteten Kette darf der Server den SNI-Namen nicht per CNAME expandieren. Der Pin gehört damit zum Paar aus Name und Port, nicht zu allen Diensten einer IP-Adresse oder jedem Mandanten desselben Hosts.

Der Client kann den angekündigten Zeitraum auf ein lokales Maximum kürzen. RFC 9102 nennt als theoretischen Angriff einen kompromittierten Server, der sieben Jahre anbietet. Eine Obergrenze begrenzt die Bindung; eine zu kurze Obergrenze schwächt jedoch den Downgrade-Schutz. Die wirksame Laufzeit entsteht aus Serverzusage und Clientpolitik.

Die kurze Uhr schützt Daten, die lange Uhr den Kanal

Ein verifiziertes TLSA-RRset darf bis zu seinem empfangenen TTL zwischengespeichert werden. Solange es frisch ist, kann der Client es verwenden, ohne bei jeder Verbindung die Erweiterung anzufordern. Nach dem TTL sind dieselben Bytes kein aktueller Beleg mehr. Läuft der Pin weiter, muss neues Material über die Erweiterung oder einen anderen DNSSEC-validen Weg beschafft werden.

TTL und RRSIG-Gültigkeit bilden die kurze Uhr. ExtSupportLifetime bildet die lange. RFC 9102 stellt ausdrücklich fest, dass die zweite nicht durch die erste begrenzt ist. Sie verlängert keine alte Signatur, sondern verpflichtet den Server, seine Kette während des Supportzeitraums zu erneuern.

Session Resumption ist ein eigener Zustand. Bei einer wiederaufgenommenen Sitzung sendet der Server kein dnssec_chain; unter TLS 1.3 fehlt außerdem die Certificate-Nachricht, an der die Erweiterung hängt. Eine Überwachung, die jedes Fehlen als Angriff wertet, erzeugt Fehlalarme. Ein belastbarer Beleg nennt Handshake-Art, TLSA-Cache, Pin-Ablauf und das tatsächlich verwendete Authentisierungsmaterial.

Bewiesene Abwesenheit und fehlende Antwort

Entfernt der Domainbetreiber TLSA, kann der Server eine NSEC- oder NSEC3-Kette liefern, die die Nichtexistenz für Name und Port authentisiert. Nach erfolgreicher Prüfung wird der Pin gelöscht. Auch ein Beleg für eine unsichere Delegation kann ihn löschen. Danach entscheidet die lokale Clientpolitik zwischen PKIX und Abbruch.

Schweigen kann das nicht. Bei aktivem Pin und ohne frisches TLSA im Cache muss der Client eine Erweiterung mit gültigem TLSA oder gültigem Abwesenheitsbeleg verlangen. Bleibt sie aus, muss er die Kommunikation anhalten oder abbrechen, bis er die Evidenz anderweitig DNSSEC-valid beschafft. Gelingt das nicht, endet die TLS-Verbindung. Andernfalls könnte ein Angreifer mit einem PKIX-akzeptierten Zertifikat das DANE-Material ausblenden und den Client unbemerkt herabstufen.

Deshalb ist die Pflicht zur Erweiterung keine Pflicht zu ewigem TLSA, DANE oder DNSSEC. Der Zone Operator darf TLSA oder sogar den DS-Eintrag entfernen. Während eines verbliebenen Pins muss der Dienst jedoch den neuen Zustand authentisiert zeigen. Das positive Ergebnis darf wechseln; seine Nachweisbarkeit darf nicht verschwinden.

Geordnetes Abschalten beginnt mit null

Wer die Erweiterung außer Betrieb nehmen will, setzt ExtSupportLifetime zunächst in einem DANE-authentisierten Handshake auf null. Danach bleibt der Support bestehen, bis alle früher ausgegebenen nichtnulligen Laufzeiten abgelaufen sein können. Erst dann darf die Erweiterung verschwinden. TLSA oder DNSSEC können vorher enden, sofern der Server für alte Pins weiterhin den passenden negativen Beleg liefert.

In Hosting-Umgebungen verteilt sich diese Reihenfolge über Organisationen. Der Domaininhaber kontrolliert DNS und will den Provider wechseln können; der Provider betreibt womöglich Zertifikate, TLS-Endpunkte und Kettenerzeugung. RFC 9102 empfiehlt non-zero Laufzeiten deshalb nur bei gegenseitigem Einverständnis. Jeder Clusterknoten muss die größte noch wirksame Zusage kennen.

Der Server setzt mit der gelieferten Kette auch nicht den eigenen Vertrauensanker. Der Client validiert ab einem vorkonfigurierten DNSSEC Trust Anchor, muss dessen Rollover verfolgen und benötigt eine hinreichend genaue Uhr für RRSIG. In-band-Transport ersetzt die DNS-Abfrage, nicht die externe Wurzel der Autorität.

RFC 9102 bleibt ausdrücklich experimentell. In der TLS Working Group gab es Bedenken, dass Pinning die Bereitstellung erschwert; das Experiment soll genau das untersuchen. Die geprüften öffentlichen Quellen belegen keine heutige Verbreitung. Sie belegen aber eine wertvolle Zustandsgrenze: positive Aussage, authentisierte Verneinung und ausbleibende Antwort dürfen nicht denselben Entscheidungsweg nehmen.

Quellen