1. Einführung (Introduction)
1.1. Hintergrund und Motivation (Background and Motivation)
Anwendungen, die über das Internet kommunizieren, müssen oft Abhören, Manipulation oder Fälschung ihrer Kommunikation verhindern. Das Transport Layer Security (TLS)-Protokoll bietet diese Art von Kommunikationssicherheit über das Internet durch Kanalverschlüsselung.
Die Sicherheitseigenschaften von Verschlüsselungssystemen hängen stark von den verwendeten Schlüsseln ab. Wenn geheime Schlüssel offengelegt werden oder wenn öffentliche Schlüssel durch gefälschte Schlüssel ersetzt werden können (d. h. ein Schlüssel, der nicht der im Zertifikat identifizierten Entität entspricht), bieten diese Systeme wenig oder keine Sicherheit.
TLS verwendet Zertifikate, um Schlüssel und Namen zu binden. Ein Zertifikat kombiniert einen veröffentlichten Schlüssel mit anderen Informationen wie dem Namen des Dienstes, der den Schlüssel verwendet, und diese Kombination wird von einem anderen Schlüssel digital signiert. Einen Schlüssel in einem Zertifikat zu haben, ist nur hilfreich, wenn man dem anderen Schlüssel vertraut, der das Zertifikat signiert hat. Wenn dieser andere Schlüssel selbst offengelegt oder ersetzt wurde, ist seine Signatur wertlos, um irgendetwas über den ersten Schlüssel zu beweisen.
Im Internet wurde dieses Problem jahrelang durch Entitäten gelöst, die "Zertifizierungsstellen" (CAs) genannt werden. CAs schützen ihren geheimen Schlüssel energisch, während sie ihren öffentlichen Schlüssel an die Softwareanbieter liefern, die TLS-Clients erstellen. Sie signieren dann Zertifikate und liefern diese an TLS-Server. TLS-Client-Software verwendet eine Reihe dieser CA-Schlüssel als "Vertrauensanker", um die Signaturen auf Zertifikaten zu validieren, die der Client von TLS-Servern erhält. Client-Software erlaubt typischerweise jeder CA, nützlich jedes andere Zertifikat zu signieren.
Das öffentliche CA-Modell, auf das sich TLS verlassen hat, ist grundlegend anfällig, da es jeder dieser CAs erlaubt, ein Zertifikat für jeden Domainnamen auszustellen. Eine einzige vertrauenswürdige CA, die ihr Vertrauen verrät, entweder freiwillig oder durch weniger als energische Schutz ihrer Geheimnisse und Fähigkeiten, kann die Sicherheit untergraben, die von allen mit TLS eingesetzten Zertifikaten geboten wird. Dieses Problem entsteht, weil eine kompromittierte CA ein Ersatzzertifikat ausstellen kann, das einen gefälschten Schlüssel enthält. Jüngste Erfahrungen mit Kompromittierungen von CAs oder ihren vertrauenswürdigen Partnern haben zu sehr ernsten Sicherheitsproblemen geführt, wie etwa Regierungen mehrerer Länder, die versuchen, wichtige TLS-geschützte Websites abzuhören und/oder zu unterwandern, denen Millionen von Benutzern vertrauen.
Die DNS Security Extensions (DNSSEC) bieten ein ähnliches Modell, das vertrauenswürdige Schlüssel beinhaltet, die die Informationen für nicht vertrauenswürdige Schlüssel signieren. DNSSEC bietet jedoch drei bedeutende Verbesserungen. Schlüssel sind an Namen im Domain Name System (DNS) gebunden, anstatt an beliebige identifizierende Zeichenfolgen; dies ist für Internetprotokolle bequemer. Signierte Schlüssel für jede Domain sind online über eine einfache Abfrage mit dem Standard-DNSSEC-Protokoll zugänglich, sodass es kein Problem mit der Verteilung der signierten Schlüssel gibt. Am wichtigsten ist, dass die mit einem Domainnamen verbundenen Schlüssel nur von einem Schlüssel signiert werden können, der mit dem Elternteil dieses Domainnamens verbunden ist; zum Beispiel können die Schlüssel für "example.com" nur von den Schlüsseln für "com" signiert werden, und die Schlüssel für "com" können nur vom DNS-Root signiert werden. Dies verhindert, dass ein nicht vertrauenswürdiger Unterzeichner die Schlüssel von irgendjemandem außer denen in ihren eigenen Subdomains kompromittiert. Wie TLS verlässt sich DNSSEC auf öffentliche Schlüssel, die in die DNSSEC-Client-Software eingebaut sind, aber diese Schlüssel kommen nur von einer einzigen Root-Domain und nicht von einer Vielzahl von CAs.
Die DNS-basierte Authentifizierung benannter Entitäten (DANE) bietet die Option, die DNSSEC-Infrastruktur zu verwenden, um Schlüssel und Zertifikate zu speichern und zu signieren, die von TLS verwendet werden. DANE wird als bevorzugte Grundlage für die Bindung öffentlicher Schlüssel an DNS-Namen angesehen, da die Entitäten, die für die Bindung von öffentlichen Schlüsseldaten an DNS-Namen bürgen, dieselben Entitäten sind, die für die Verwaltung der fraglichen DNS-Namen verantwortlich sind. Während das resultierende System immer noch Restsicherheitsschwachstellen aufweist, beschränkt es den Umfang der Behauptungen, die von jeder Entität gemacht werden können, in Übereinstimmung mit dem durch die DNS-Hierarchie auferlegten Namensumfang. Infolgedessen verkörpert DANE das Sicherheitsprinzip des "geringsten Privilegs", das im aktuellen öffentlichen CA-Modell fehlt.
1.2. Sicherung der Zuordnung eines Domainnamens zum Zertifikat eines Servers (Securing the Association of a Domain Name with a Server's Certificate)
Ein TLS-Client beginnt eine Verbindung, indem er Nachrichten mit einem TLS-Server austauscht. Bei vielen Anwendungsprotokollen schlägt er den Namen des Servers mit dem DNS nach, um eine mit dem Namen verbundene Internet Protocol (IP)-Adresse zu erhalten. Dann beginnt er eine Verbindung zu einem bestimmten Port an dieser Adresse und sendet dort eine Anfangsnachricht. Der Client weiß jedoch noch nicht, ob ein Gegner seine Kommunikation abfängt und/oder ändert, bevor sie den TLS-Server erreicht. Er weiß nicht einmal, ob der echte TLS-Server, der mit diesem Domainnamen verbunden ist, jemals seine Anfangsnachrichten erhalten hat.
Die erste Antwort vom Server in TLS kann ein Zertifikat enthalten. Damit der TLS-Client authentifizieren kann, dass er mit dem erwarteten TLS-Server spricht, muss der Client validieren, dass dieses Zertifikat mit dem Domainnamen verbunden ist, den der Client verwendet hat, um zum Server zu gelangen. Derzeit muss der Client den Domainnamen aus dem Zertifikat extrahieren und das Zertifikat erfolgreich validieren, einschließlich der Verkettung zu einem Vertrauensanker.
Es gibt eine andere Möglichkeit, die Zuordnung des Zertifikats des Servers zum beabsichtigten Domainnamen zu authentifizieren, ohne einer externen CA zu vertrauen. Da der DNS-Administrator für einen Domainnamen berechtigt ist, identifizierende Informationen über die Zone zu geben, ist es sinnvoll, diesem Administrator auch zu erlauben, eine autoritative Bindung zwischen dem Domainnamen und einem Zertifikat herzustellen, das möglicherweise von einem Host unter diesem Domainnamen verwendet wird. Der einfachste Weg, dies zu tun, ist die Verwendung des DNS und die Sicherung der Bindung mit DNSSEC.
Es gibt viele Anwendungsfälle für eine solche Funktionalität. [RFC6394] listet diejenigen auf, auf die der DNS-RRtype in diesem Dokument anwendbar ist. [RFC6394] listet auch viele Anforderungen auf, von denen die meisten von diesem Dokument erfüllt werden sollen. Abschnitt 5 behandelt die Anwendbarkeit dieses Dokuments auf die Anwendungsfälle im Detail. Das Protokoll in diesem Dokument kann allgemein als "DANE TLSA"-Protokoll bezeichnet werden. ("TLSA" steht für nichts; es ist nur der Name des RRtype.)
Dieses Dokument gilt sowohl für TLS [RFC5246] als auch für Datagram TLS (DTLS) [RFC6347]. Um das Dokument lesbarer zu machen, spricht es hauptsächlich nur über "TLS", aber in allen Fällen bedeutet es "TLS oder DTLS". Obwohl sich die Verweise in diesem Absatz auf TLS und DTLS Version 1.2 beziehen, kann das DANE TLSA-Protokoll auch mit früheren Versionen von TLS und DTLS verwendet werden.
Dieses Dokument bezieht sich nur auf die sichere Zuordnung von Zertifikaten für TLS und DTLS zu Hostnamen; das Abrufen von Zertifikaten aus DNS für andere Protokolle wird in anderen Dokumenten behandelt. Zum Beispiel werden Schlüssel für IPsec in [RFC4025] behandelt, und Schlüssel für Secure SHell (SSH) werden in [RFC4255] behandelt.
1.3. Methode zur Sicherung von Zertifikatszuordnungen (Method for Securing Certificate Associations)
Eine Zertifikatszuordnung wird aus einer Information gebildet, die ein Zertifikat identifiziert, und dem Domainnamen, auf dem die Serveranwendung läuft. Die Kombination eines Vertrauensankers und eines Domainnamens kann auch eine Zertifikatszuordnung sein.
Eine DNS-Abfrage kann mehrere Zertifikatszuordnungen zurückgeben, wie im Fall eines Servers, der von einem Zertifikat zu einem anderen wechselt (detaillierter in Anhang A.4 beschrieben).
Dieses Dokument gilt nur für PKIX [RFC5280]-Zertifikate, nicht für Zertifikate anderer Formate.
Dieses Dokument definiert eine sichere Methode, um das vom TLS-Server erhaltene Zertifikat mit einem Domainnamen unter Verwendung von DNS zu verknüpfen; die DNS-Informationen müssen durch DNSSEC geschützt werden. Da die Zertifikatszuordnung auf der Grundlage einer DNS-Abfrage abgerufen wurde, ist der Domainname in der Abfrage per Definition mit dem Zertifikat verbunden. Beachten Sie, dass dieses Dokument nicht behandelt, wie Zertifikate mit Domainnamen für Anwendungsprotokolle verknüpft werden, die von SRV, NAPTR und ähnlichen DNS-Ressourcendatensätzen abhängen. Es wird erwartet, dass zukünftige Dokumente Methoden für die Herstellung dieser Zuordnungen abdecken werden, und diese Dokumente können dieses möglicherweise aktualisieren müssen oder auch nicht.
DNSSEC, das in [RFC4033], [RFC4034] und [RFC4035] definiert ist, verwendet kryptographische Schlüssel und digitale Signaturen, um die Authentifizierung von DNS-Daten bereitzustellen. Informationen, die aus dem DNS abgerufen und mit DNSSEC validiert werden, sind dadurch als autoritative Daten nachgewiesen. Die DNSSEC-Signatur muss bei allen Antworten validiert werden, die DNSSEC verwenden, um den Nachweis der Herkunft der Daten zu gewährleisten.
Dieses Dokument spezifiziert nicht, wie die DNSSEC-Validierung erfolgt, da es viele verschiedene Vorschläge gibt, wie ein Client validierte DNSSEC-Ergebnisse erhalten könnte, wie z. B. von einem DNSSEC-bewussten Resolver, der in der Anwendung codiert ist, von einem vertrauenswürdigen DNSSEC-Resolver auf der Maschine, auf der die Anwendung läuft, oder von einem vertrauenswürdigen DNSSEC-Resolver, mit dem die Anwendung über einen authentifizierten und integritätsgeschützten Kanal oder Netzwerk kommuniziert. Dies wird in Abschnitt 7 von [RFC4033] ausführlicher beschrieben.
Dieses Dokument bezieht sich nur auf das sichere Abrufen der DNS-Informationen für die Zertifikatszuordnung unter Verwendung von DNSSEC; andere sichere DNS-Mechanismen liegen außerhalb des Geltungsbereichs.
1.4. Terminologie (Terminology)
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [RFC2119] beschrieben zu interpretieren.
Dieses Dokument verwendet auch die Standardterminologie für PKIX, DNSSEC, TLS und DNS. Siehe [RFC5280], [RFC4033], [RFC5246] und STD 13 [RFC1034] [RFC1035] für diese Begriffe. Darüber hinaus stammen Begriffe im Zusammenhang mit TLS-geschützten Anwendungsdiensten und DNS-Namen aus [RFC6125].