DANE disruptiv: Authentifizierte OpenPGP-Schlüssel im DNS
Pretty Good Privacy soll das DNS zur Schlüsselpropagierung nutzen. Auf der Liste der Entwickler der Internet Engineering Task Force (IETF) steht als nächstes die Zulassung eigenen Schlüsselmaterials.
Für immer mehr Anwendungen wird die Authentifizierung über DNSSEC-gesicherte Domains vorangetrieben. Nach der Absicherung des E-Mail-Transports SMTP durch die Hinterlegung von TLSA-Records im DNS soll jetzt Pretty Good Privacy das DNS zur Schlüsselpropagierung nutzen. Die Zulassung von "Raw Keys" – eigenen Schlüsselmaterials – steht als nächstes auf der Liste der Entwickler der Internet Engineering Task Force (IETF).
Die Möglichkeit eines "Unified key management", bei dem Schlüsselmateral für diverse Anwendungen bei der zugehörigen Domain abgelegt wird, ist laut Olafur Gudmundsson, Chef der IETF-Arbeitsgruppe, nicht nur eine "Killer-App" für das bislang nur zögerlich eingeführte DNSSEC. Es habe das Zeug, den Markt kräftig aufzumischen, nicht zuletzt, weil Unternehmen damit Hunderttausende Euro an Zertifikatsgebühren einsparen können.
An der OpenPGP DANE-Spezifikation fehlen nur noch wenige Striche, eine Implementierung hat Red-Hat-Entwickler Paul Wouters auf GitHub veröffentlicht. Er meint, innerhalb von zwei Wochen könne das Dokument in den RFC-Publikationszyklus geschickt werden. Statt Public Keys auf einer langen Liste von Schlüsselservern zu hinterlegen, kann die signierte Domain künftig der natürliche Anlaufpunkt für den öffentlichen PGP-Schlüssel werden.
Vorteile von Open PGP
Das hat gleich mehrere Vorteile. Das Schlüsselmaterial ist mit einer Abfrage zu finden, nämlich durch eine Frage an den DNS-Server der Maildomain, und zwar im Format xxx.openpgp.heise.de. Ganz links steht ein Sha224-Hash des lokalen Teils der E-Mail-Adresse. Durch den Hash werden die Sonderzeichen des lokalen Teils vermieden. Zweitens liefert die Variante mehr Sicherheit als die Hinterlegung bei einem klassischen PGP-Schlüsselserver. Denn durch die DNSSEC-Signierung der Domain ist mindestens sichergestellt, dass der Domaininhaber die Schlüsselhinterlegung veranlasst hat. Drittens ist laut RFC-Entwurf der Rückruf eines Schlüssels einfacher. Bei unabhängigen PGP-Schlüsselservern muss dazu beim Upload der Schlüssel eigens ein Revocation Key erstellt werden. Unter der signierten Domain ist die Erneuerung des Schlüssels einfacher.
Einmal implementiert, ermöglicht die Hinterlegung der öffentlichen PGP-Schlüssel bei der zugehörigen Domain eine automatisierte Schlüsselabfrage und Verschlüsselung der zu sendenden E-Mail durch MTA und MUA. Wouters' Implementierung ersetzt dabei auch den Betreff, der als "encrypted mail" ausgegeben wird.
Dem Mailprovider beziehungsweise ISP, der die Zone signiert und den Schlüssel dort hinterlegt, muss man freilich noch vertrauen, räumt Wouters ein. Überdies ist die DNSSEC-Signierung der Mail-Domain Voraussetzung. Schlüssel in nicht signierten Zonen werden unter anderem zur Abwehr von Spoofing-Attacken verworfen.
Trotz der Absicherung mit DANE SMTP und DANE OpenPGP sieht Wouters durchaus Bedarf für eine DANE-Variante von SMIME, an der parallel gearbeitet wird. "OpenPGP ist dazu gedacht, Daten während des Transports und während der Speicherung auf den Servern dritter abzusichern." Ein Ersatz für die Identifizierung der Person mit der man zu sprechen glaube, sei es nicht.
"Rohe Schlüssel"
Wouters stellte in Toronto auch einen Vorschlag von EFF-Entwickler Dan Gilmore vor, der die bisherige Festlegung von DANE auf Zertifikaten explizit beenden soll. DANE soll künftig gerade nicht nur die X.509 PKIX-Zertifikate zulassen. Vielmehr soll auch anderes Schlüsselmaterial via signierte Domain als authentifiziert akzeptiert werden können. Die Domainsignatur des Registrars oder der Registry würde an die Stelle der Zertifikatsanbieter treten.
Statt jeweils eigene RFCs für neue Anwendungen zu machen, sollte TLSA flexibel auch für andere Dienste genutzt werden können, die nicht auf PKIX-Zertifikate setzen. DANE würde generischer. Interesse daran gibt es schon jetzt in der Jabber-Gemeinde und neuerdings auch in der Arbeitsgruppe, die sich um den IP-Telefoniestandard SIP kümmert sowie bei den Arbeiten rund um die Überwindung von Network Address Translation (NAT).
DANE-Update
Ein generisches DANE macht allerdings ein Update am ursprünglichen RFC erforderlich. Doch die DANE-Arbeitsgruppe erwägt ohnehin, auf Basis der von SMTP DANE-Autor Viktor Dukhovni erarbeiteten Empfehlungen für den DANE-Einsatz bald eine neue Version (DANEbis) der Grundspezifikation zu machen, wie Gudmundson bestätigt. Da könnten die rohen Nicht-PKIX-Schlüssel gleich mit aufgenommen werden. Dukhovni und sein Ko-Autor Wes Hardecker warnen in den Richtlinien vor möglichen Downgrade-Attacken, wenn Clients sowohl PKIX als auch reine Domainzertifikate oder andere generische Schlüssel zulassen.
Auf die Liste fürs Update gehörten schließlich noch weitere Verbesserungen, unter anderem die Mandatierung von TLS 1.0 bei gleichzeitiger Empfehlung für spätere Versionen 1.1 und 1.2. Das ursprüngliche Dokument hatte sich dazu ausgeschwiegen.
Die Erweiterung und Zulassung generischer Schlüssel sind laut Gudmundson die logische Konsequenz der DANE-Entwicklung und könnten letztlich dafür sorgen, dass etwa Unternehmen verstärkt auf ein einheitliches Schlüsselmanagement via DNS statt auf teure Zertifikatslösungen setzen.
Wird DANEbis damit der Sargnagel fürs Zertifikatsgeschäft? Ganz offensichtlich haben Unternehmen wie VeriSign das durchaus befürchtet und ihr Zertifikatssparte bereits verkauft. Wouters meint: "Ich hoffe, dass die CA-Zertifikate verschwinden, aber es wird noch eine ganze Weile dauern, bis wir dahin kommen. Wir müssen abwarten, wie es mit DNSSEC weitergeht." (anw)
