Protokoll des Treffens "Fragen zu DNSSEC und DANE" vom 8.11.2017

- 11:00-12:00 Vortrag "DNSSEC und DANE am LRZ"
- 12:00-13:00 Vortrag "Best practices zur Einführung von DNSSEC und DANE"

Während der Vorträge und im Anschluß wurden die folgenden Themen und Fragen diskutiert:

Frage: Das empfohlene Idealsetup mit "Signing Proxy" (siehe Präsentation und Wikiseite zum Signing Proxy) benötigt mindestens drei DNS-Maschinen (Verwaltungsmaster, hidden Master "signing proxy", mind. 1x Slave). Kann man den "Signing Proxy" auch auf dem Verwaltungsmaster betreiben, um Maschinen und den damit verbundenen Verwaltungsaufwand zu sparen?

Antwort: Das empfohlene Idealsetup entstammt vor allem den Anforderungen an die sichere Handhabung der DNSSEC Privatkeys (siehe auch die nächste Frage). Der selbst ständige Signing Proxy gewährleistet, dass nur eine minimale Anzahl an Personen Zugriff auf die vorhandenen Schlüssel haben oder neue generieren können. Im praktischen Betrieb läuft der Signing Proxy eigenständig, und die Verbindung sowohl zur DNS-Verwaltung bzw. zu den öffentlichen "Slaves" erfolgt nur über Zonentransfers.

Dieses Setup hat aber zudem im Fehlerfall weitere Vorteile. Fällt der DNS-Verwaltungsserver aus, können zwar keine geänderten Zonen mehr zum Signing Proxy geschickt werden, aber der letzte intakte Stand des DNS bleibt erhalten, und die öffentlichen DNS-Server erhalten keine fehlerhaften Zonen.

Fällt wiederum der Signing Proxy selbst aus, können zwar auch keine Zonenänderungen mehr signiert und den öffentlichen DNS-Servern zur Verfügung gestellt werden, aber da der notwendige zweistufige Transfer nicht erfolgt, werden auch keine unsignierten Zonen ausgeliefert. Liefen Verwaltung und Signierung nur auf einer Maschine, würden unter Umständen unsignierte Zonen, die von validierenden Resolvern dann nicht mehr als gültig betrachtet würden, auf den DNS-Slaves ausgeliefert.

So ermöglicht dieser zusätzliche Doppelschritt der Indirektion eine wünschenswerte Fehlerabsicherung. Mit der Beibehaltung eines korrekten vorherigen DNS-Zustands bleibt mehr Zeit Fehler zu beheben.

In der Diskussion ergab es sich, dass in gewissen Konstellationen und bei geringer Verfügbarkeit an Ressourcen von Menschen und Hardware auf eine kombinierte DNS-Verwaltung mit DNSSEC-Signierung zurück gefallen werden kann, wenn es der Verbreitung von DNSSEC zu Gute kommt. Mit den damit verbundenen, oben beschriebenen, Ausfallrisiken müssen die Administratoren dann zu Recht kommen.

Frage: Wie verwahrt man die privaten DNSKEYs am besten?

Antwort: Die Empfehlung des US-amerikanischen National Institute of Standards and Technology (NIST) (siehe PDF "Secure Domain Name System (DNS) Deployment Guide" Abschnitt 9.4) ist, die privaten DNSKEYs in einem "safe store", also außerhalb der direkt oder per Netzwerk an den "signing proxy" angeschlossenen Storagemedien zu verwahren, um sie vor unberechtigtem Zugriff zu schützen.

Da die privaten Schlüssel des ZSK aber für jede Änderung von DNS-Einträgen und der damit verbundenen Neusignierung benötigt werden, ist das bei dynamischen Zonen, die sich mitunter täglich oder stündlich ändern, nicht praktikabel. Da der private KSK nur für das Signieren der ZSK verwendet wird, d.h. nur bei ZSK-rollovers, könnte man bei penibler Beachtung der Sicherheitsempfehlungen, zumindest diesen auf einem eigenständigen Medium (z.B. USB-Stick) im Tresor verwahren. ZSK-rollovers werden wiederum ebenfalls empfohlen und so müsste man immer noch enormen Aufwand im Wochen- oder Monatsrhythmus betreiben.

Nach allen praktischen Gesichtspunkten, werden also auch die privaten Schlüssel der KSK und ZSK auf dem Signing Proxy verbleiben. Daher ist es essentiell zumindest diese Maschine (ob physisch oder virtuell) vor unberechtigtem Zugriff von außen über das Netz oder durch nicht-authorisierte Mitarbeiter zu schützen. Da der Signing Proxy nicht von außen erreichbar sein muss, und nicht als autoritativer Master in Erscheinung tritt ("hidden"), ist hier die Beschränkung des Zugriffs auf DNS gewährleistet. Für die generelle Absicherung sollten die allgemeinen Sicherheitsrichtlinien beachtet werden.

Eine Alternative zur sicheren Schlüsselverwahrung bieten "Hardware Security Module"-Lösungen, die aber meist nur eine begrenzte Anzahl an Schlüsseln verwalten können (bei vielen Zonen ist das ein Problem, wenn ein KSK und ZSK pro Zone verwendet werden soll), teuer in der Anschaffung sind, und unter Umständen das notwendige Backup der Schlüssel erschweren, wenn der  Zugriff vollkommen abgeschottet ist.

Daher wird eine solche Lösung auch nicht am LRZ betrieben. Die "Zwitter-Lösung" eines Software-HSM wird in Form von OpenDNSSEC erfolgreich an der FAU in Erlangen betrieben, und ist auf dieser LRZ-Wikiseite kurz beschrieben.

Frage: Welche Gefahr droht, wenn jemand einen ZSK kompromittiert?

Antwort: Ein kompromittierter ZSK bedeutet erst einmal, dass jemand anderes als der berechtigte Zonenbetreiber in den Besitz des privaten ZSK gelangt ist. Dies kann im Prinzip durch Zurückrechnen ("knacken") erfolgen, da für den ZSK im Gegensatz zum KSK, der nur zum Signieren der DNSKEYs verwendet wird, sehr viel mehr Signaturdaten (jeder abgefragte DNS-Antwort wird damit verschlüsselt) abgreifbar sind. Dennoch ist dieser Aufwand für den noch als sicher geltenden RSASHA-2 (RFC 6234), z.B. RSASHA256, enorm hoch, und für größere Schlüsselllängen bei RSASHA512 noch höher. Dieser Aufwand ist nur von Angreifern der Größenordnung der NSA zu erbringen.

Wahrscheinlicher ist, dass der Angreifer durch einen Einbruch in die Server an das Schlüsselmaterial gelangt. Dies ist wie oben erwähnt die primäre Argumentation einen Signing Proxy zu verwenden.

Ist der Angreifer im Besitz des vollständigen ZSK, kann er von ihm generierte DNS-Antworten im Namen des Zoneninhabers valide signieren. Das DNS-Paket besteht aus der Klartextantwort (DNS ist auch mit DNSSEC unverschlüsselt) und korrekter Signatur über die Daten und den privaten ZSK, wird von einem validierenden Resolver verifiziert und als authentisch betrachtet. Damit ist grundsätzlich eine Einschleusung einen falscher Antwort und damit ein Umleiten der Client auf eine durch den Angreifer kontrollierte Maschine möglich.

Die größere Schwierigkeit liegt allerdings darin, die gefälschten Antworten dem Client unter zu schieben. Der Angreifer könnte zwar einen kompletten gefälschten Nameserver betreiben, aber der Client würde diesen nicht abfragen. Die NS-Einträge in der Parentzone verweisen immer noch auf den rechtmäßigen Nameserver, und der Hash des KSK ebenso. Damit bleibt nur eine direkte MITM-Attacke auf den DNS-Antwortstrom direkter DNS-Antworten, um falsche DNS-Antworten an den Client zu leiten.

Das birgt zwar Gefahrenpotential, ist aber keine komplette Übernahme der Zonenhoheit des rechtmäßigen Nameservers.

Zudem muss man sich fragen, wie groß die Motivation eines Angreifers ist, die DNS-Antworten einer Universität oder Hochschule anzugreifen.

Frage: Es wird empfohlen ZSKs zu "rollen", da diese kompromittiert worden sein können. Wie weiß man, dass der Schlüssel kompromittiert wurde?

Antwort: Rein aus DNS/DNSSEC-Sicht ist das äußerst schwierig. Da das Angriffsszenario, wie in der vorhergehenden Frage beschrieben, nur als MITM-Attacke auftreten würde, werden dem Nameserverbetreiber keine gefälschten Antworten bekannt, da diese ihm nicht gesendet werden, sondern nur dem Client.

Daher kann man nur aus den Spuren und Indizien einer Komprottierung des Signing Proxies darauf schließen, dass DNSSEC-Schlüssel in die falschen Hände geraten sein könnten. Darum, und aus Gründen der allgemeinen IT-Sicherheit, sollte man durch regelmäßige Loganalyse, Firewalls, und IDS (oder gar IPS) Angriffsversuche zu entdecken versuchen.

Wird ein erfolgreicher Einbruch vermutet, ist das Schlüsselmaterial als kompromittiert anzusehen, und muss gemäß des (eingeübten!) Key-rollover-Prozesses ausgetauscht werden.

Diskussion über ein rein Windows-basiertes DNSSEC-Setup

Herr Karl-Heinz Dees von der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt erläuterte uns sein rein auf Windows 2016 Server basierendes Setup an Nameservern und erzählte von seinen Erfahrungen bei der Einführung von DNSSEC. Dieses Setup setzt ebenfalls einen dedizierten Signing Proxy ein und besteht insgesamt aus vier Windowsservern. Eine zusätzliche Windowsinstanz bei der DFN fungiert als dritter öffentlicher "secondary" DNS-Server.

Eine Windows 2016 Instanz wird zur DNS-Verwaltung genutzt, die Version 2016 hat hier den Vorteil, die vollständigste Unterstützung von DNSSEC (SSHFP-Resource records, NSEC3) auf der Windowsplattform zu bieten. Windows bietet ein bequemes Schlüssselmanagement bei dem ZSK anhand der definierten Schlüsselgültigkeit automatisch erzeugt werden, und auch die entsprechenden pre-publish Zeiten eingehalten werden. Es können Standby-Keys definiert und die Signierperiode für Zoneneinträge festgelegt werden.

Die GUI ermöglicht die Definition "moderner" Resource Records wie SSHFP, allerdings noch keine TLSA-Einträge. Diese lassen sich aber wie Herr Dees heraus fand, über die Powershell erstellen und der Zone hinzufügen. Damit bietet Windows 2016 Server alle notwendigen Möglichkeiten von der DNSSEC-Seite DANE zu unterstützen, während MS Exchange noch nicht dazu in der Lage ist, diese Informationen für einen DANE-verifizierten Versand zu nutzen.

Über die selbe Methode hat Herr Dees auch in der Zone entsprechende CAA-Einträge hinterlegt, um die Ausstellung von Zertifikaten auf bestimmte CAs gemäß RFC 6844 zu beschränken.

Frage: Sollte man auch TLSA-Einträge für https-Zertifikate (Port 443) im DNS hinterlegen?

Antwort: TLSA-Einträge können grundsätzlich für alle Arten von TLS-Zertifikaten im DNS hinterlegt werden. Dies ermöglicht auch die zusätzliche Absicherung von https-Verbindungen durch "Zertifikat-Pinning". Bisher gibt es allerdings keinen Browser, der dies nativ unterstützt. Es gibt aber DANE/TLSA-Validatoren von unabhängigen Entwicklern als Plugin für Firefox, Chrome und Internet Explorer.

Ob und wann die gängigen Webbrowser DANE/TLSA nativ unterstützen werden ist unbekannt. Google sträubte sich gegen die Einführung, die im Quellcode schon enthalten war, da es einerseits die Sicherheit des ursprünglich verwendeten 1024 Bit langen root-KSK bemängelt, und zum anderen wohl Zertifikatsabsicherung mittels OCSP Stapling vorzieht.

Das bedeutet, dass man der Vollständigkeit halber, oder um die Sichtbarkeit von DANE zu fördern, gerne TLSA-Einträge für TCP Port 443 erstellen kann, dies aber derzeit nur in einem sehr kleinem Kreis von Nutzern Beachtung finden wird.

Frage: Welche anderen Anwendungen profitieren von DNSSEC und DANE?

Antwort: Auch XMMP-basierte Instantmessenger ("Jabber") benutzen weitest gehend TLS-Zertifikate zur Absicherung der Client-Server-Kommunikation. Wie bei allen TLS-basierten Verschlüsselung hängt die Sicherheit vom Vertrauen in das präsentierte Zertifikat ab, und ist bei der herkömmlichen PKI-Überprüfung von Vertrauen in die Root-CAs abhängig. Damit sind wie schon an anderer Stelle hier im LRZ-Wiki erläutert, eine Vielzahl von Problemen verknüpft (Ausgabe falscher Zertifikate, Zertifikate als ungültig deklarieren usw.), so dass man nicht mehr volles Vertrauen darin haben kann.

Da sich mit DANE auch hier selbst-signierte Zertifikate authentisch absichern lassen, so dass sie dem Serverbetreiber über das DNS eindeutig zugeordnet werden können, ist es sehr sinnvoll und zu empfehlen, für diese Anwendungen TLSA-Zertifikate für die jeweiligen Server/Ports als TLSA-Resourcerecord zu hinterlegen.

Wenn die TLS-gesicherten Server von anderen Administratoren als den DNS-Verwaltern betrieben werden, ist bei Wechsel der Zertifikate Kommunikation von Nöten. Durch Verwendung eines TLSA-Eintrags des Typs 3 1 1, (EE - Public key hash - RSASHA256) ist das aber nur noch bei Wechsel des zum Signieren des Zertifikats verwendeten Public keys nötig. Dies erfolgt im allgemeinen in einem längeren Rhythmus als die Zertifikatserneuerung.

Frage: Wo profitiert man von der Einführung von DNSSEC, abgesehen von der authentischen Absicherung der DNS-Antworten auf dem Übertragungsweg?

Antwort: Da mit DNSSEC authentische Antworten garantiert sind, kann kryptographisch relevante Information im DNS abgelegt werden, und Anwendungen sich auf die erhaltenen Antworten als unverfälscht verlassen. Da die Nameserver im allgemeinen im selben Administrationsbereich (auch wenn andere Personen dafür verantwortlich sein mögen) der jeweiligen Serverbetreiber, die abgesichert werden sollen, liegen, profitieren Anwender direkt davon.

Als Beispiele hierfür seien die Hinterlegung von ssh-Fingerprints für Loginserver mittels SSHFP-Resource records (RFC 6594), oder von S/MIME-Zertifikaten genannt. Auch Schlüssel für OpenPGP können so, gemäß des - noch als experimentel deklarierten - RFC 7929, hinterlegt und Benutzern zugeordnet werden.

Frage: Sollte man aufgrund der Verschiebung des Root-KSK-Rollover auf die "1. Hälfte 2018" mit der Einführung von DNSSEC warten?

Antwort: Nein, eine solche Vorsicht ist nicht angebracht. Alle moderne Nameserversoftware (BIND, Unbound, Windows 2016 Server, Knot DNS) haben mittlerweile einen Automatismus zum Beziehen des root-KSK, für Details siehe unsere Wikiseite zum KSK Rollover. Die Einführung von DNSSEC bringt langfristig Vorteile und trotz des nach außen hin großen "Media-Hype" über den KSK-Rollover stellt dieser keine Gefahr für das Funktionieren von DNSSEC dar - sofern man sich der Aktualität der verwendeten Nameserversoftware vergewissert hat. Es gibt also keinen Grund deshalb die Einführung von DNSSEC auf den eigenen Nameservern zu verschieben!

Frage: Sollte man DKIM, SPF und DMARC für Kommunikation zwischen MTAs verwenden? Was ist dabei zu beachten?

Antwort: Vordergründig haben die genannten Techniken nichts mit DNSSEC und DANE zu tun. Die Gemeinsamkeiten gründen sich aber auf den Wunsch, Emailkommunikation authentisch zu bewerkstelligen. Im Gegensatz zu DANE, das den Empfänger als authentisch ausweist, wird hier das Fälschen von Absenderadressen erschwert

Da ein public-key-Verfahren das gängigste Prinzip der Authentifizierung zwischen Absender und Empfänger darstellt, und dies ohne geheimen Austausch eines nur beiden Parteien bekannten Schlüssels funktioniert, stossen die Techniken in dieselbe Richtung.

Auch im Falle von DKIM (RFC 6376), SPF (RFC 7208, RFC 7372) und DMARC (IETF Draft RFC7489) werden die öffentlichen Schlüssel (DKIM) und Anweisungen wie mit Mails einer Domain unter Verwendung der Information aus DKIM und SPF verfahren werden sollte (DMARC), im DNS hinterlegt. Da dafür keine Protokollerweiterung, wie im Falle von DNSSEC, durchgesetzt wurde, werden diese im allgemeinen txt Resource record als definierte Felder hinterlegt.

NB: Grundsätzlich hilft hier DNSSEC am Rande mit seiner garantierten Authentizität diesen txt-Einträgen in der DNS-Antwort zu vertrauen.

Da im Falle von SPF aber gemäß RFC 4408 empfohlen wird, Domains ohne SPF-Einträge nicht negativ zu bewerten, stellt dies kein Allheilmittel gegen Spam dar.

Das LRZ hat für die Domäne, lrz.de, in der sich auch der Posteingangsserver befindet, von den hier aufgenannten Techniken nur einen SPF-Eintrag gesetzt:

v=spf1 redirect=_spf.mail.lrz.de

der wie üblich zuerst die verwendete Version, spf1, angibt, und dann mit redirect auf den SPF-Record der Domain _spf.mail.lrz.de verweist, der wie folgt gesetzt ist, um den Mailversand auf die Maschinen in den angegeben IP-Bereichen zu beschränken. Alle anderen werden mit einem Softfail, ~all, ausgeschlossen:

v=spf1 ip4:129.187.254.0/23 ip6:2001:4ca0:0:103::/64 ~all

NB: Übungen auf den DNSSEC-Workshop-VMs

Den Teilnehmern wurde angeboten, dass nach Einarbeitung in die Theorie, IP-Freischaltungen auf den Workshop-VMs, die für die gehaltenen DNSSEC-Workshops verwendet wurden, erfolgen können. Das soll Ihnen die Möglichkeit geben die in den damalig verteilten Unterlagen beschriebenen Übungen per Fernzugriff durch zu führen. In Absprache mit Daniel Feuchtinger kann dies auch unter Anleitung per Mail erfolgen.