QUIC kommt quicker: IETF bringt neues Internet-Transportprotokoll voran

Inhaltsverzeichnis

70 bis 80 Prozent des Internet-Verkehrs könnten schon bald über das neue Transportprotokoll QUIC laufen. So schätzen es Experten ein, die an der Entwicklung der Spezifikation bei der Internet Engineering Task Force beteiligt sind (IETF). Bei der Ende März gelaufenen 98. IETF in Chicago wurde zugleich deutlich, dass für die Balance zwischen Vertraulichkeit auf Kryptografiebasis einerseits und dem Netzwerk-Management andererseits noch einiges auszuhandeln ist.

Der Drive der Arbeiten am Quick UDP Internet Connections Protocol ist bemerkenswert. 2014 hatten Googles QUIC-Entwickler eine IETF-Standardisierung noch ausgeschlossen. Aber schon zwei Jahre später starteten die ersten Arbeiten zur Umsetzung bei der IETF. "Ist das jetzt Googles QUIC? Nein, das ist es nicht mehr", erklärte Entwickler Jana Iyengar bei einem QUIC-Tutorial. An der Verschlüsselung, an der Gestaltung von Header-Feldern und anderen Teilen der ursprünglichen Spezifikation wurde kräftig Hand angelegt. Stück für Stück arbeiten die Entwickler jetzt eine Liste von Änderungsvorschlägen ab, eine lange Liste, seufzt Iyengar.

Neue Header, neue Crypto

Einen großen Brocken hat die Arbeitsgruppe weitgehend bewältigt: Das Format des QUIC-Headers steht nun. QUIC wird über eine lange und eine kurze Header-Version verfügen. Die Langversion enthält noch etwas mehr Informationen, mit Bits zur Angabe von Protokoll-Typ, Connection-ID, Paketnummer und QUIC-Version. Nach dem Verbindungsaufbau reicht die Kurzversion, die nur noch Typ und Paketnummer übermittelt, die Connection-ID bleibt als Option. Der Inhalt der Pakete ist von Anfang an verschlüsselt, kein großer Unterschied zu HTTPS. Dass jetzt aber auch ein Teil der Header-Information verschlüsselt und damit den Blicken Dritter verborgen bleibt, das ist eine Neuerung – und sie ist umstritten. Als Verschlüsselungsprotokoll kommt künftig TLS 1.3 zum Einsatz und zwar anstatt der ursprünglich von Google genutzten hauseigenen Crypto-Variante.

Die Google-Entwickler hätten zwar ihre eigene Verschlüsselung ebenfalls bei der IETF zur Standardisierung einbringen können. Doch weil die IETF mit der Weiterentwicklung von TLS zu TLS 1.3 rasch nachgezogen hatte und zudem QUIC-gemäß einen verschlüsselten Kanal umgehend aufbaut (Zero Round Trip), fiel die Wahl darauf. Nur beim allerersten Verbindungsaufbau fehlt die Verschlüsselung noch, es wird aber immerhin authentifiziert.

Vertraulichkeit und Netzwerkmanagement

Das Mehr an Verschlüsselung, insbesondere der Verlust an Metadaten aus dem Header, beschert der QUIC-Arbeitsgruppe die vielleicht schwierigste Diskussion. Die Hersteller von Firewalls und anderen Mittelboxen und die Netzbetreiber klagen, dass Congestion Control, Trouble Shooting und Netzwerk-Management insgesamt schwieriger werden. Sie ringen daher um mehr Klartextinformationen im Header. Bei TCP können sie die erforderlichen Informationen aus den Headern saugen.

Ein neuer Vorschlag, den Mirja Kühlewind, Vorsitzende der Transport Area und Wissenschaftlerin an der ETH Zürich vorgestellt hat, regt unter anderem das Zurückspielen (Echoing) von einzelnen oder allen Paketnummern an, um passives Monitoring der Verbindungen zu erlauben (passive RTT measurement). Noch ungelöst aus Sicht der Netzwerk-Management-Vertreter, ist die Frage, wie die Zero-Round-Trip-Verbindungen identifiziert werden können. Bei der Neuaufnahme einer Verbindung mit bekanntem Server geht es nämlich gleich in die voll verschlüsselte Version – mit schweigsamem Header.

Innerhalb der Arbeitsgruppe wird die Forderung nach mehr Bits fürs Netzwerk-Management zurückgewiesen, nicht nur von Privacy-Vertretern wie Daniel Kahn Gillmor von der American Civil Liberties Union. Lars Eggert, Vorsitzender der QUIC-Arbeitsgruppe, sagte gegenüber heise online, er sei nicht überzeugt von der Notwendigkeit. Und Iyengar merkte an, die Standardentwicklung der IETF sei schließlich nicht wertneutral. Sie halte sich an das Prinzip, dass Dritte, die nicht vom Endpunkt autorisiert wurden, keinen Anspruch darauf haben, Informationen zu bekommen, die nicht für sie bestimmt sind. Ganz offensichtlich gibt die Arbeitsgruppe dem Schutz von Metadaten Vorrang.

Rasanter Fortschritt

Trotz solcher Grundsatzfragen soll die QUIC-Spezifikation schon im Sommer soweit festgezurrt sein, dass Implementierungen getestet werden können, sagt Eggert. Der harte Kern der QUIC-Arbeitsgruppe, fast fünfzig Entwickler von Google, Mozilla, Microsoft, Akamai und anderen Firmen, trifft sich daher regelmässig auch zwischen den IETF-Konferenzen. Die nächste Sitzung findet schon im Frühsommer in Paris statt. (dz)