4. Verwendung von TLSA-Einträgen in TLS (Use of TLSA Records in TLS)

Abschnitt 2.1 dieses Dokuments definiert die obligatorischen Übereinstimmungsregeln für die Daten aus den TLSA-Zertifikatszuordnungen und den vom TLS-Server empfangenen Zertifikaten.

Die einzurichtende TLS-Sitzung MUSS für die spezifische Portnummer und den Transportnamen sein, die in der TLSA-Abfrage angegeben wurden.

Einige Spezifikationen für Anwendungen, die über TLS laufen, wie [RFC2818] für HTTP, erfordern, dass das Zertifikat des Servers einen Domainnamen hat, der mit dem vom Client erwarteten Hostnamen übereinstimmt. Einige Spezifikationen, wie [RFC6125], beschreiben detailliert, wie die in einem PKIX-Zertifikat angegebene Identität mit den vom Benutzer erwarteten Identitäten abgeglichen wird.

Wenn ein TLSA-Eintrag Zertifikatsverwendung 2 hat, SOLLTE der entsprechende TLS-Server das referenzierte Zertifikat senden, genau wie er derzeit Zwischenzertifikate sendet.

4.1. Verwendbare Zertifikatszuordnungen (Usable Certificate Associations)

Eine Implementierung dieses Protokolls führt eine DNS-Abfrage für TLSA-Einträge durch, validiert diese Einträge mit DNSSEC und verwendet die resultierenden TLSA-Einträge und den Validierungsstatus, um ihre Antworten an den TLS-Server zu ändern.

Die Bestimmung, ob ein TLSA-RRSet verwendet werden kann, MUSS auf dem DNSSEC-Validierungsstatus basieren (wie in [RFC4033] definiert).

• Ein TLSA-RRSet, dessen DNSSEC-Validierungsstatus sicher ist, MUSS als Zertifikatszuordnung für TLS verwendet werden, es sei denn, eine lokale Richtlinie würde die Verwendung der spezifischen Zertifikatszuordnung im sicheren TLSA-RRSet verbieten.

• Wenn der DNSSEC-Validierungsstatus für die Antwort auf die Anfrage des TLSA-RRSets gefälscht ist, MUSS dies dazu führen, dass TLS nicht gestartet wird oder, wenn die TLS-Verhandlung bereits läuft, MUSS dies dazu führen, dass die Verbindung abgebrochen wird.

• Ein TLSA-RRSet, dessen DNSSEC-Validierungsstatus unbestimmt oder unsicher ist, kann nicht für TLS verwendet werden und MUSS als unbrauchbar betrachtet werden.

Clients, die die DNSSEC-Signaturen selbst validieren, MÜSSEN Standard-DNSSEC-Validierungsverfahren verwenden. Clients, die sich auf eine andere Entität verlassen, um die DNSSEC-Signaturvalidierung durchzuführen, MÜSSEN einen sicheren Mechanismus zwischen sich und dem Validator verwenden. Beispiele für sichere Transporte zu anderen Hosts umfassen TSIG [RFC2845], SIG(0) [RFC2931] und IPsec [RFC6071]. Beachten Sie, dass es nicht ausreicht, einen sicheren Transport zu einem DNS-Resolver zu verwenden, der keine DNSSEC-Signaturvalidierung durchführt. Siehe Abschnitt 8.3 für weitere Sicherheitsüberlegungen im Zusammenhang mit externen Validatoren.

Wenn eine Zertifikatszuordnung eine Zertifikatsverwendung, einen Selektor oder einen Übereinstimmungstyp enthält, der vom TLS-Client nicht verstanden wird, MUSS diese Zertifikatszuordnung als unbrauchbar betrachtet werden. Wenn die Vergleichsdaten für ein Zertifikat fehlerhaft sind, MUSS die Zertifikatszuordnung als unbrauchbar betrachtet werden.

Wenn eine Zertifikatszuordnung einen Übereinstimmungstyp oder Zertifikatszuordnungsdaten enthält, die einen kryptografischen Algorithmus verwenden, der für die Richtlinie des TLS-Clients als zu schwach angesehen wird, MUSS die Zertifikatszuordnung als unbrauchbar betrachtet werden.

Wenn eine Anwendung null verwendbare Zertifikatszuordnungen von einer DNS-Anfrage oder aus ihrem Cache erhält, verarbeitet sie TLS auf normale Weise ohne Eingabe von den TLSA-Einträgen. Wenn eine Anwendung eine oder mehrere verwendbare Zertifikatszuordnungen erhält, versucht sie, jede Zertifikatszuordnung mit dem Endentitätszertifikat des TLS-Servers abzugleichen, bis eine erfolgreiche Übereinstimmung gefunden wird. Während des TLS-Handshakes MUSS der TLS-Client den Handshake abbrechen, wenn keine der Zertifikatszuordnungen mit dem vom TLS-Server angegebenen Zertifikat übereinstimmt.

Ein Angreifer, der in der Lage ist, einen Benutzer zu einem Server unter seiner Kontrolle umzuleiten, kann wahrscheinlich auch DNS-Anfragen vom Benutzer oder DNS-Antworten, die an den Benutzer gesendet werden, blockieren. Um einen Sicherheitsvorteil aus Zertifikatsverwendung 0 oder 1 zu erzielen, muss eine Anwendung, die eine Anfrage für TLSA-Einträge sendet, entweder eine gültige signierte Antwort mit TLSA-Einträgen oder eine Bestätigung erhalten, dass die Domain unsicher oder unbestimmt ist. Wenn eine Anfrage für einen TLSA-Eintrag keines dieser beiden Kriterien erfüllt, die Anwendung aber trotzdem mit dem TLS-Handshake fortfährt, hat die Anwendung keinen Nutzen aus TLSA gezogen und SOLLTE KEINE interne oder externe Anzeige dafür machen, dass TLSA angewendet wurde. Wenn eine Anwendung eine Konfigurationseinstellung hat, die die TLSA-Verwendung aktiviert hat, oder eine Anzeige dafür hat, dass TLSA verwendet wird (unabhängig davon, ob dies konfigurierbar ist oder nicht), DARF diese Anwendung ENTWEDER KEINE TLS-Verbindung starten ODER sie MUSS einen TLS-Handshake abbrechen, wenn beide oben genannten Kriterien nicht erfüllt sind.

Die Anwendung kann die TLSA-Suche vor dem Initiieren des TLS-Handshakes durchführen oder dies während des TLS-Handshakes tun: Die Wahl liegt beim Client.