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 [1] 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 [2] fehlen nur noch wenige Striche, eine Implementierung [3] 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 [4] 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 [5] k�mmert sowie bei den Arbeiten rund um die �berwindung von Network Address Translation [6] (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 [7] 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." (Monika Ermert) / (anw [8])
Keine Kommentare:
Kommentar veröffentlichen