Schlüssel zum DNS
Seite 3: Es geht auch einfacher
Es geht auch einfacher
DNS-CERT verteilt komplette Zertifikate und Schlüssel über die Nameserver. Obwohl sie diese Aufgabe anstandslos bewältigen, sind sie ursprünglich nicht für die Übertragung größerer Datenmengen konzipiert worden. Dies ist beispielsweise auch daran erkennbar, dass das Host-Kommando für DNS-Antworten mit mehr als rund 1500 Bytes in den TCP-Modus wechseln muss und eine entsprechende Fehlermeldung ausgibt. Standardmäßig verwendet DNS UDP. RFC4398 widmet daher dem Performance-Aspekt ein eigenes Kapitel.
Das bislang nur für PGP-Schlüssel eingesetzte und wesentlich einfachere PKA-Verfahren[4] trägt dem Umstand Rechnung, dass diese in der Regel über Keyserver erhältlich sind. Es benutzt deshalb ähnlich dem Sender Policy Framework das TXT-Feld von DNS-Einträgen, um nur die Meta-Informationen Fingerprint und Bezugsquelle zu transportieren. Ein Beispiel-RR für Bind9 sieht folgendermaßen aus:
cr._pka 86400 IN TXT \
"v=pka1;fpr=761D[...]264E;uri=http://intern.heise.de/cr.asc"
Typisch für PKA ist die Einrichtung einer neuen, virtuellen Subdomäne mit den Namen _pka. Um aus einer E-Mail-Adresse die abzufragende Domain zu erhalten, muss man lediglich das @-Zeichen durch ._pka. ersetzen. v=pka1 spezifiziert die derzeit einzige Protokollversion PKAv1. Nach fpr= ist der Fingerabdruck des Schlüssels angegeben und uri= beschreibt die Quelle, unter der der Schlüssel abrufbar ist.
Werner Koch, Geschäftsführer der GnuPGP-Entwicklerfirma g10 Code, betreibt derzeit für seine E-Mail-Adresse werner@fsfe.org einen funktionsfähigen PKA-Eintrag:
$ host -t txt werner._pka.fsfe.org
werner._pka.fsfe.org descriptive text \
"v=pka1;fpr=A4D94[...]58A2;uri=finger:wk@g10code.com"
Sogar der in der URI angegebene Finger-Server zum Abruf seines PGP-Schlüssels ist mit finger wk@g10code.com erreichbar. Sofern Koch seiner Signatur mit der gpg-Option -N pka-address@gnupg.org=werner@fsfe.org die notwendige PKA-Notation hinzufügt, nimmt GnuPG ab Version 1.4.3 bei Verwendung der Option --auto-key-locate die zur Validierung seiner Signaturen notwendigen Schritte automatisch vor. PKA befindet sich noch allerdings noch in der Entwicklung. Für die Zukunft soll eventuell auch ein eigener Resource Record beantragt werden, um nicht mehr den Umweg über den TXT-RR gehen zu müssen.
Biegen und Brechen
Ansätze wie DNS-CERT und PKA bilden eine sinnvolle Weiterentwicklung sich etablierender Anti-Spam-Technologien wie SPF und DomainKeys. Sie ermöglichen dabei nicht nur die Authentifizierung von E-Mail-Servern, sondern auch der einzelnen Kommunikationspartner. Ein funktionierendes Verteilungssystem für S/MIME-Zertifikate ist ohnehin schon längst überfällig.
Ein großflächiger Einsatz von DNS-CERT und PKA würde das DNS zusätzlicher Belastung aussetzen. Ob es dieser gewachsen ist, bleibt abzuwarten. Ein unerwünschter Effekt bei PKA und DNS-CERT ist darüber hinaus, dass durch die DNS-Anfragen Informationen über die Kommunikationsgewohnheiten der Anwender nach außen gelangen.
Der Pferdefuß einer DNS-basierten Lösung ist jedoch die derzeit mangelhafte Sicherheit des Domain Name System. Der Aufwand für die Fälschung einer Identität reduziert sich auf das Fälschen eines DNS-Eintrags, und manipulierte DNS-Einträge sind leider noch an der Tagesordnung. Daher ist der ernsthafte Einsatz von DNS für die Übertragung kritische Daten keinesfalls zu empfehlen, so lange es keine ausreichende Sicherheit vor Manipulationen bietet. Und bis dahin ist es noch ein langer Weg.
Literatur
[1] Storing Certificates in the Domain Name System (DNS)
[2] Resource Records for the DNS Security Extensions
[3] makecertrrs.pl, Perl-Skript von VeriSign zur CERT-RR-Erstellung
[4] Public Key Association, Hintergrundpaper von Werner Koch (cr)
