Original-URL des Artikels: https://www.golem.de/news/ietf-netzwerker-wollen-quic-pakete-tracken-1707-129072.html    Veröffentlicht: 21.07.2017 15:56    Kurz-URL: https://glm.io/129072

IETF

Netzwerker wollen Quic-Pakete tracken

Eigentlich kommt die Standardisierung des Quic-Protokolls gut voran. Doch Netzwerker und um Privatsphäre besorgte Entwickler streiten sich schon jetzt heftig darüber, ob und wie Quic-Pakete verfolgt werden können. Und das hat wohl auch sehr große Auswirkungen auf das gesamte Internet.

Die erste Sitzung der Quic-Arbeitsgruppe auf dem IETF Meeting 99, das derzeit in Prag stattfindet, startet mit Erfolgsmeldungen aus dem Hackathon, der am Wochenende vor dem Meeting stattgefunden hat. Dass diese Erfolge auf der Sitzung von nur einem Thema verdrängt werden und viele andere neue Vorschläge für Quic vorerst nicht mehr diskutiert werden können, zeigte sich im Grunde aber schon beim Streit um die "statischen Schlüssel" für TLS 1.3.

Erste echte Datenübertragungen

Zunächst zu den Erfolgen: Auf dem Hackathon haben es die Beteiligten geschafft, mit unterschiedlichen Implementierungen, die sich an den vorliegenden Entwurf halten, eine Interoperabilität zu erreichen. So sind Handshakes erfolgreich durchgeführt und auch schon einige Daten in einem sehr geringen Umfang unter speziellen Bedingungen ausgetauscht worden.

Laut Mark Nottingham, dem Co-Vorsitzenden dieser sowie der HTTP-Arbeitsgruppe, ist dieser laufende Code ein "wichtiger Meilenstein" sowie ein "vielversprechender Start". Er hoffe außerdem, so Nottingham, dass die Leute jetzt begreifen, dass das von der IETF standardisierte Quic Wirklichkeit werde.

Das Vertrauen der Entwickler in den Erfolg von Quic ist sogar schon so weit gediehen, dass diese kurz diskutieren, ob und unter welchen Umständen das sogenannte Wire-Format bereits eingefroren werden soll. Dies wird aber unter anderem auch deshalb vorerst verworfen, weil Google sehr negative Erfahrungen mit seiner eigenen Quic-Version habe.

Verschiedene Middleboxen, also Rechner und Geräte auf den Transportwegen zwischen Client und Server, benutzen inzwischen einige spezifische Bytes, um Quic-Pakete erkennen zu können. Google habe deshalb aber das Problem, sein Format nicht mehr ändern zu können. Bei dem IETF-Quic, das auf der Grundlage von Googles Ideen und Erkenntnissen entsteht, soll dies wohl aber so lange wie möglich hinausgezögert werden.

Diskussion um Roundtrip-Messungen

Dass darüber hinaus aber nur noch ein weiteres Thema von der Tagesordnung besprochen werden würde, hat der zweite Co-Vorsitzende der Quic-Arbeitsgruppe, Lars Eggert, vermutlich schon geahnt. Unmittelbar vor der Quic-Sitzung sagte er im Treffen des Security-Arbeitsbereichs der IETF, dass er die Diskussionen um die statischen Schlüssel bei TLS 1.3 mit "großem Interesse" verfolgt habe.

Vermutlich war für Eggert schon abzusehen, dass ein Vorschlag für Quic ähnlich heftige und beherzte Diskussionen auslösen würde und derartige Streits auch langfristig Teil des Prozesses der Standardisierung von Quic sein würden. Im konkreten Fall ist erläutert worden, dass Netzwerkbetreiber zur Qualitätsverbesserung und für das Trafficmanagement die Paketumlaufzeit (Round Trip Time) bestimmen.

Anders als bei TCP ist bei dem auf UDP basierenden Quic aber fast der gesamte Traffic absichtlich verschlüsselt. Das betrifft insbesondere auch die ACKs, weshalb das Bestimmen der RTT bei Quic durch die Netzwerkbetreiber nicht mehr trivial möglich ist. Der Google-Angestellte Ian Swett stellte deshalb mögliche Lösungen für das Problem vor (PDF).

Die Diskussion dieser Lösungen sorgte allerdings für eine ähnlich klare Spaltung in zwei Fraktionen, wie dies bereits bei TLS der Fall gewesen ist.

Es geht um mehr als Quic

Die erste Option, die Swett vorschlägt, ist schlicht, nichts aktiv zu unternehmen und innerhalb von Quic alles so zu belassen wie bisher. Befürworter der Idee, aktive Hilfe im Protokoll bereitzustellen, um die RTT zu messen, bevorzugen den Vorschlag, Pakete mit einem bestimmten "Spin-Value" zu versenden. Dem Vortrag zufolge sollen das etwa eine Reihe spezieller Bits sein, die vom Initiator der Verbindung mit verschickt werden.

Das Gegenüber bekommt diesen Wert und sendet diesen Wert dann einfach in Response-Paketen zurück. Der Initiator kann dann anschließend den Spin-Wert einfach vertauschen. Netzwerkbetreiber haben damit leicht die Möglichkeit, den Umlauf von Paketen zu analysieren, um eventuelle Steuerungsmaßnahmen treffen zu können.

Fürchterliche Probleme für die Privatsphäre

Für den Informatiker Daniel Kahn Gillmor, der für die US-Bürgerrechtsorganisation ACLU arbeitet, löst der Vorschlag zum Messen der RTT große Bedenken aus. Immerhin wisse niemand, welche tatsächlichen negativen Konsequenzen diese Vorgehen für Internetnutzer haben könnte.

So könnte die RTT unter anderem für eine grobe Lokalisierung der Nutzer eingesetzt werden, und der Vorschlag habe ganz klar noch weitere Auswirkungen auf die Privatsphäre der Nutzer. Das sei angesichts der Kenntnisse über TCP offensichtlich und Gillmor sagt, er sei darüber "enttäuscht".

Sehr ähnlich argumentiert auch der Mozilla-Angestellte Eric Rescorla, der sichtbar aufgeregt vorträgt, dass alle Anwesenden die "fürchterlichen Probleme von TCP für die Privatsphäre" ebenso kennen wie die große Anzahl an Attacken auf Nutzer, die diese Probleme ausnutzen. Quic sollte diese eigentlich lösen.

Vertreter von Netzwerkbetreibern befürchten dagegen, dass ihnen mit Quic sehr viele Möglichkeiten fehlen werden, typische Congestion-Probleme zu verhindern und damit keine gute Qualität der Verbindung liefern können. Mirja Kühlewind, Forscherin an der ETH Zürich, wirft zudem ein, dass ihr die negativen Konsequenzen für die Netzwerke ohne derartige Hilfsmittel viel klarer sind als alle andere Erwägungen.

Große Einigkeit auf Seiten der Netzwerker besteht für den Vorschlag mit der Bitsequenz auch deshalb, weil sie das Vorgehen hier für vergleichsweise sehr minimalistisch erachten, um ihre Ziele erreichen zu können. Den Versuch des Minimalismus muss auch Gillmor anerkennen.

Erstmal Fakten sammeln

Zu einem Schluss oder gar einer Entscheidung kann die Arbeitsgruppe bei derart harten Fronten vorerst nicht kommen. Das müssen auch die Vorsitzenden Nottingham und Eggert anerkennen, die, statt die Diskussion abzubrechen und mit der Tagesordnung weiter zu verfahren, den Beteiligten zunächst jedoch noch möglichst viel Zeit zum Austausch einräumen.

Für Ruhe und einen etwas versöhnenden Abschluss in der Debatte sorgt der für die Quic-Arbeitsgruppe zuständige IETF-Area-Director Spencer Dawkins. Dieser berichtet davon, dass sowohl die Verantwortlichen der IESG als auch des IAB bereits derartige Diskussionen geführt haben.

Dawkins gibt deshalb zu bedenken, dass solche Diskussion und eventuelle Entscheidungen deutlich über die Quic-Arbeitsgruppe hinausreichen. Ebenso spricht Dawkins von einem sehr informierten Vortrag, den Rescorla gehalten habe, um über mögliche Probleme und Auswirkungen aufmerksam zu machen.

Wie nicht anders zu erwarten, entscheiden die Vorsitzenden Nottingham und Eggert, das Thema auf das nächste Meeting der IETF zur vertagen. Alle Interessierten werden schließlich dazu aufgefordert, bis dahin entsprechende Fakten zu sammeln, die ihre Positionen und Befürchtungen unterstützen. Zuvor will das Team auf einem Interimstreffen aber noch mal an der Interoperabilität der unterschiedlichen Implementierungen arbeiten.  (sg)


Verwandte Artikel:
IETF: DNS wird sicher, aber erst später   
(20.07.2017, https://glm.io/129049 )
Verschlüsselung: TLS 1.3 ist so gut wie fertig   
(16.02.2018, https://glm.io/132828 )
Streaming: Akamai macht Videos mit Quic schneller   
(23.03.2017, https://glm.io/126898 )
Dual EC: Wie Cisco, Avast und die NSA TLS 1.3 behindern   
(19.12.2017, https://glm.io/131758 )
Internet-Protokoll: Quic soll der neue Kick für sicheres Surfen werden   
(07.11.2016, https://glm.io/123738 )

© 1997–2019 Golem.de, https://www.golem.de/