IETF 99: Mehr Privacy über verschlüsselten DNS-Transport
[ad_1]
Spätestens seit den Snowden-Enthüllungen weiß man, dass DNS-Anfragen viel über das Nutzerverhalten preisgeben. Jetzt versprechen gleich drei Arbeitsgruppen mehr Privacy und die IETF hat die Qual der Wahl.
Der Vorschlag, DNS-Anfragen TLS-verschlüsselt zu übertragen, bekommt Konkurrenz: Gleich zwei neue Techniken für den Transport von DNS-Anfragen diskutierten Experten bei der 99. Internet Engineering Task Force (IETF) in Prag. Sie sollen nicht nur effektiver gegenüber aktuellen Verfahren arbeiten, sondern auch mehr Privatheit gewährleisten.
DNS-Anfragen geben einen Schatz an Metadaten preis, aus denen zum Beispiel DNS-Resolver-Betreiber einiges über das Verhalten eines Nutzers auslesen können: Welche Seiten besucht er im Internet, welche Mail-Server verwendet er und von wem bezieht er gerade den Schlüssel für die nachfolgende verschlüsselte Kommunikation. Je nach Konfiguration und Durchgangsstationen der DNS-Pakete lassen sich auch Standort und MAC-Adresse des Anfragenden PC oder Smartphone auslesen. Daher sind neue DNS-Anfrage-Techniken wünschenswert, die weniger Metadaten preisgeben. Eine deutliche Verbesserung verspricht die RFC-Spezifikation 7858, DNS over TLS, an der die IETF seit 2016 arbeitet.
Nicht ausreichend
Damit bauen Client und Server einen verschlüsselten Tunnel mittels Transport Layer Security auf. Inzwischen sind mit Unbound und Knot erste DNS-Server mit TLS nachgerüstet und man kann die Technik auf Testinstallationen ausprobieren. Parallel schreitet die Entwicklung des dazu passenden User-Clients Stubby voran. Stubby ist aktuell für Linux und macOS erhältlich, Windows wird später berücksichtigt. DNS-Anfragen und -Antworten reisen also durch einen TLS-Tunnel zwischen Stubby auf dem PC sowie dem Resolver und können unterwegs nicht von Dritten gelesen werden. Das ist zwar ein deutlicher Gewinn, aber manche Entwickler sind damit nicht zufrieden.
ICANN-Entwickler Paul Hoffman und sein Mozilla-Kollege Patrick McManus werben für den Umzug des DNS-Verkehrs auf den Port 80 und zwar auf das neue, verschlüsselnde HTTP/2. Dabei kann der Absender DNS-Anfragen wahlweise im Header (GET) oder im Body (POST) der HTTP/2-Pakete stecken. Außerdem wollen Hoffman und sein Co-Autor Applikationsentwicklern die DNS-Nutzung erleichtern. Der volle Umfang der DNS-Dienste, zu denen DNSSEC, DANE und SRV gehören, stehe App-Entwicklern bisher gar nicht zur Verfügung.
DNS über HTTP/2 könnte den Mangel für Browser und Apps beseitigen. Notwendig sei, DNS-Servern HTTP/2 beizubringen. Hoffman versichert jedoch: “Das ist schnell gemacht”. Große Anbieter wie Google seien sehr daran interessiert. Dass dadurch große Plattformen DNS-Anfragen an sich ziehen, mache keinen Unterschied. “Wer sucht sich denn heute seinen DNS-Resolver selbst aus?”, fragt Hofmann, ignoriert dabei aber offenbar fortgeschrittene Nutzer und Unternehmen, die eigene Resolver betreiben.
DNS über Quic
Auch die neue Quic-Fraktion macht dem RFC 7858 Konkurrenz. Das UDP-basierte Quic verspricht verschlüsselte Verbindungen und ein Ende verschiedener klassischer Probleme wie Head-of-Line-Blocking. DNS über Quic biete sowohl die Datenschutzvorzüge des RFC 7858 als auch die bisher übliche Effizienz der DNS-Kommunikation über UDP, warb Microsoft Entwickler Christian Huitema in Prag. Clients müssten ihre Anfragen über einen separaten Port an DNS-Server schicken.
Die Idee fand einige Zustimmung, darunter auch beim ehemaligen Vorsitzenden des Internet Architecture Board (IAB), Andrew Sullivan. Allerdings warnte er davor, das Protokoll auf die Strecke zwischen Stub-Resolvern – also dem PC des Nutzers – und dem rekursiven DNS-Server zu beschränken. Der zweite Teil, die Kommunikation zwischen den rekursiven Servern und den authoritativen Servern müsse ebenfalls berücksichtigt werden.
Doch viele Experten kritisierten den Quic-Vorstoß als unverantwortlich. Er sorge nur für Verwirrung bei den Resolver-Betreibern, etwa denen, die erwägen, ihre rekursiven Server jetzt mit DNS-over-TLS nachzurüsten.
Sarah Dickinson, DNS-Privacy-Expertin von Sinodun, räumt ein, dass die Situation unübersichtlich sei. DNS über HTTP sei natürlich von der Browsergemeinde angetrieben. Gleichzeitig gebe es in der Quic-Arbeitsgruppe sehr viel Interesse daran, DNS einzubinden. Es sei auch für die Absicherung der Kommunikation mit den authoritativen Servern gut geeignet. Für die erste Strecke bis zum Resolver glaubt sie immer noch an das RFC 7858. “Aber es ist sehr viel Bewegung” und es noch offen, welches der Verfahren sich durchsetzen wird. (dz)
[ad_2]
Read more on: Source