SMIMEA - Type53

Wenn DNS-Informationen per DNSSEC abgesichert werden, dann kann DNS auch für die Verteilung für Schlüsselmaterial genutzt werden. Interessant ist dies z.B. für Public Keys von Webserverm, SMTP-Servern aber auch für einzelne Mailadressen. Genau dies beschreibt der DNS-Eintrag SMIMEA bzw. Type 53

Warum ein SMIME-Zertifikat im DNS ?

Wer heut verschlüsselt bzw. signiert senden will, muss mit Schlüsselmaterial hantieren und das muss er erst einmal haben. Hier gibt es wieder die zwei Fälle:

  • Ich möchte signiert senden
    Dazu reicht mein eigener privater Schlüssel aber die Empfängerseite muss irgendwie prüfen können, ob diese Signatur korrekt ist. Daher sende ich meinen öffentlichen Schlüssel in Form eines Zertifikats mit, welches aber von einer "Trusted CA" signiert sein muss. Könnte ich im DNS aber meinen "Public Key" per DNSSEC gesichert veröffentlichen, dann könnte der Empfänger so direkt die Gültigkeit prüfen und wir wären von der PKI-Struktur unabhängig
  • Ich möchte verschlüsselt senden
    Dazu brauch ich den PublicKey der Empfängerseite. Hat dieser mir den schon mal zugesendet und ich habe ihn in meine Kontakte übernommen, dann kann ich diesen nutzen. Elegant wäre es aber auch hier, wenn der Sender einfach per DNS nachfragen könnte., ob der Empfänger SMIME-Mails annehmen will. Wenn ich als Sender per DNS den Public Key bekomme, dann kann ich sofort verschlüsselt senden.

Es hat also schon seine Vorteile im DNS die öffentlichen Schlüssel für Mailadressen zu hinterlegen um damit mit entsprechend ausgestatteten Mailservern und Mailclients direkt SMIME zu nutzen. Voraussetzung ist aber eine Absicherung per DNSSEC, nicht dass ein Geheimdienst oder andere Personen die DNS-Abfrage zu verfälschen, dass dem Versender ein anderer Schlüssel gemeldet wird und damit andere Personen die Mails abfangen lesen und neu verschlüsselt versenden können. Das Risiko ist zwar gering aber warum sollte man heute bei einem neuen Standard eine Schwachstelle einbauen?

Technische Umsetzung

Wer heute eine E-Mail an vorname.nachname@example.com sendet, übergibt diese Mail an einen Mailserver. Die Mail kann dazu schon auf dem Client verschlüsselt werden oder ein Gateway auf dem Weg verschlüsselt die Mails. Den dazu erforderlichen "Public Key" bezieht die Software in diesem Beispiel per DNS, genauso wie sie den MX-Record für eine Domäne abruft. Nur wird diesmal kein A-Record, TXT-Record oder MX-Record abgefragt. Stattdessen haben einige Leute in einem RFC-Draft (https://tools.ietf.org/html/draft-ietf-dane-smime-09) einen neuen DNS Ressource Record definiert.

Für jede Mailadresse, die einen SMIME-Schlüssel veröffentlichen will, ist ein eigener DNS-Eintrag erforderlich. Das ist natürlich nicht ganz so einfach, da ein Anwender sicher nicht die DNS-Zone der Firma bearbeiten kann. Ganz kleine Firmen oder interessierte Privatpersonen werden die Einträge wohl von Hand vornehmen, wenn der DNS-Hoster diese Einträge überhaupt unterstützt. Größere Firmen werden sich ein geeignetes Provisoining überlegen, z.B. um die Daten aus dem Active Directory Feld zu extrahieren und für alle Benutzer zu veröffentlichen.

Damit aber nun nicht gleich eine Liste der Mailadressen per DNS "Ausprobierbar" wird, nutzt der aktuelle Entwurf einen Hashwert über den Userpart. Und das geht wie folgt:

  • Wir nehmen z.B. meine Mailadresse frank.smime@msxfaq.de (Die Adresse gibt es nicht wirklich)
    Diese Adresse besteht lässt sich anhand des "@" Zeichens in zwei Teile trennen, den Localpart (frank.smime) und den Domainpart (msxfaq.de)
    Der Domainpart definiert, in welcher DNS-Zone der Eintrag vorgenommen werden muss und der LocalPart wird für den nächsten Schritt benötigt
  • Localpart "Hashen"
    Niemand will Mailadressen "sichtbar" im DNS ablegen. Daher wird der Localpart nur als Hashwert gespeichert und damit auch hier Sonderzeichen und zukünftige Erweiterungen abgedeckt sind, werden die Zeichen als "UTF-8" (Unicode) codiert und mittels SHA2-256 als Hashwert umgesetzt. Damit der Wert nun nicht zu lange wird, wird der Hash auf 28 Octets gekürzt und hexadezimal geschrieben. DAs können Sie per Powershell sogar recht einfach machen:
$localpart= [system.Text.Encoding]::UTF8.GetBytes('frank.smime')
$hasher = [System.Security.Cryptography.HashAlgorithm]::create('sha256')
$hash = $hasher.ComputeHash($localpart)
$dnslocalpart=[System.BitConverter]::Tostring($hash).replace("-","").Substring(0,56)
  • "._smimecert" addieren
    Nach dem Hashwert wird dann der String "._smimecert" angehängt. Das ist der Schreibweise von SRV-Records sehr ähnlich.
  • Payload
    Der Datenbereich für den Record besteht nun aber nicht nur aus dem Zertifikat, sondern enthält noch drei Werte vorab, die der Beschreibung bei TLSA entsprechend. Drei Bytes geben Auskunft über. (Details siehe https://tools.ietf.org/html/rfc6698#section-2.1  )

Wenn man all das dann zusammen setzt, erhält man einen Eintrag in der Form

08485C1A4C662F161D312664F3E15FBF5C434EB1549BBEE001D21627._smimecert.carius.de SMIMEA 0 0 1 xxxxxxxxxxx

Als xxx findet sich dann z.B. hier das komplette Zertifikat, mit dem ein Absender die Mails verschlüsseln oder die Signatur von eingehenden Mails prüfen könnte.

Ich frage mich natürlich, warum die Autoren hierfür einen extra RR-Type angefordert haben. Nach meiner Einschätzung hätte es auch ein TXT-Record getan, der schon heute in jedem DNS-Server gepflegt werden kann. Windows Phone kann aktuell (2015) ja nicht mal SRV-Records auflösen.

Delegation in DNS

Der Trick nach jedem Hash-Wert noch eine ".smimecert" zu addieren erlaubt es einem Administrator, diese DNS-Zone zu delegieren. Das hat durchaus Vorteile

  • Unterschiedliche Zoneneinstellungen (TTL etc.)
    Sie können z.B. über den SOA-Record einstellen, dass der TTL für die Zone "_smimecert.<firma-tld>" abweichend von den Einstellungen der Zone <firma.tld> ist
  • Unterschiedliche Administratoren
    Bei vielen Systemen können Sie pro Zone die Administration steuern. Das ist wichtig, wenn der "Mail-Admin" die SMIME-Zertifikate publizieren soll aber bitte nicht ihre A-Einträge der Firmendomäne
  • Unterschiedliche DNS-Server
    Durch die Delegierung können Sie diese Zone natürlich auch auf andere DNS-Server legen. Das hilft, wenn ihre Stammzone beim Hostingprovider für ihre Webseite liegt und sie die SMIME-Einträge auf einem DNS-Server eines anderen Providers oder bei sich ablegen wollen. Gerade die Ablage beim Provider kann interessant sein, wenn das Thema Verschlüsselung und Signatur ausgelagert wird.

Einschätzung

Der Ansatz ist interessant und sicher eine RFC wert. Ich befürchte aber, dass es sich nicht durchsetzen wird. Zum einen braucht man natürlich DNSSEC, um die Zertifikatinformationen sicher bereit zu stellen. Das ist aber weniger das Problem. Ich denke eher, dass die Bereitstellung eines neuen Typ lange dauern wird und diverse Resolver und Produkte erst erweitert oder entwickelt werden müssen. Zudem müssen die Anwender oder Firmenadministratoren diese Informationen natürlich erst publizieren. Entsprechende APIs und Programme müssen dann ganz viele Hoster und ganz viele Administratoren bereit stellen.

Ich werde das Thema sicher weiter betrachten und ich würde mich freuen, wenn so die Verbreitung von SMIME gefördert wird. Aber erst wenn die Mailclients auf Mobiltelefonen und PCs ohne AddOns diese Anfragen "einbauen" und auch das Keyhandling auf den Clients einfacher möglich ist, dann könnte es was werden. Ich bin immer noch ein Fan von einer Gateway-Lösung (Verschlüsseln und Signieren auf dem Gateway): , indem ich die Verbindung zwischen Client und Server danke SSL und Anmeldung als ausreichend "sicher" ansehe und alle Mails, die mein System verlassen oder erreichen auf der Schnittstelle verschlüsselt und signiert, decodiert und verifiziert werden. Dann wäre mit aber ein DNS-Eintrag, der diesen Servern den Weg zu den Schlüsselservern der Firma weist, der logischere Weg.

Zumal der Abruf von kompletten Zertifikaten per DNS oft größere Datenmengen sind, die nicht mehr in eine UDP-Antwort passen. Auch hier müsste man dann dann Sicherungsmechanismen oder gleich DNS/TCP nutzen. für eine einfache Abfrage reicht UDP locker aus und ist auch sehr effektiv. für Zertifikate könnte HTTPS vielleicht besser sein.

Die Schlüssel würde ich dann auch eher z.B. auf einem Webserver oder WebService ablegen und im DNS nur den Verweis darauf einbringen. Der WebService kann ja per HTTPS/SSL gesichert sein und der dort verwendete Schlüssel könnte über DANE/TLSA hinterlegt sein.

Weitere Links