Stéphane Bortzmeyer

The Drink authoritative server was created both to have dynamic answers (such as the IP address of the resolver) and to be used as a platform for DNS experimentation. The talk will present its internal implementation and the choices made.

Drink is written in Elixir and makes use of several Elixir strengths, notably the parallelism, which is very important for a DNS server. Also, writing an Internet server means dealing with broken (or downright hostile) clients so robustness is important. We will discuss the technical decisions, their consequences, and the remaining problems.

Découverte du langage de programmation Elixir, avec du concret (des serveurs et clients Internet).

Certes, les participant·es aux JDLL sont un peu saturé·es d’exposés « Le langage X, plus meilleur trop bien que tous les autres ». Aussi, je ne vais pas raconter qu’Elixir est mieux que tout, juste parler de son caractère fonctionnel, de ses possibilités de parallélisme, des bibliothèques utiles qu’il offre, et de trois logiciels (libres, bien sûr) de production qui l’utilisent. (Pour celles et ceux qui hésitent encore : Elixir compile des programmes pour les exécuter sur la machine virtuelle d’Erlang, mais je vous rassure tout de suite, sa syntaxe n’a rien à voir avec celle d’Erlang.)

Many people are unhappy with the current state of the Web: pervasive user tracking, a lot of distractions from the actual content, so complicated that it is very hard to develop from scratch a new browser. Why not going back to the future, with a protocol and format focused on lightweight distribution of content? This is Gemini, both a new ultra-simple protocol and a simple format. Not to develop an alternative to YouTube but useful to access content with a minimal client. Gemini is not "retro" but it "looks retro".

Panorama des solutions pour le programmeur dans un Internet 100 % chiffré.

Aujourd'hui, tout le trafic sur Internet est (ou devrait être) chiffré. Mais cela empêche d'utiliser des techniques de déboguage comme l'excellent logiciel Wireshark, qui nous montrait en détail tout ce qui passait sur le réseau. Nous allons voir ici les techniques qui permettent de continuer à examiner les messages qu'on envoie et reçoit. De la communication de la clé de sessions par les programmes qui communiquent (plus compliqué s'il y a confidentialité persistente) à l'Homme du Milieu (qu'utilise par exemple Pi-Hole) aux fonctions de déboguage réseau avancées que, normalement, toute application et toute bibliothèque devrait fournir.

Of course, encrypting DNS is necessary for privacy and security, like for every other Internet protocol. That's why DoT and DoH deployment is very important, so that users could safely go to a resolver they trust. Now, it is time to assert the technical compliance and performance of these trusted resolvers. We will talk about the things that could and should be tested against DoT and DoH servers and how to implement it. We will then discuss performance measurements, specially with the opportunities brought by parallelism (both in DoT and DoH) and the challenges they create for measurements. This talk will be inspired by the development of a tool which is, at this stage, in a very alpha state.

QUIC, désormais largement déployé, et depuis peu normalisé [enfin, si le RFC est publié d'ici novembre, c'est pas gagné], est un concurrent de TCP. TCP était auparavant *le* protocole de transport de l'Internet, à part quelques cas particuliers. QUIC est un concurrent, supposé diminuer la latence, notamment pour les requêtes HTTP. (HTTP/3 est juste HTTP-sur-QUIC.) QUIC n'est pas juste un changement technique, il a suscité beaucoup de débats politiques, ce sera donc l'occasion de parler de sujets comme l'ossification de l'Internet, la possibilité de déployer des nouveautés rapidement, le pouvoir des éditeurs de navigateurs, le désir de dissimuler au réseau ce qu'on lui exposait avant, cf. RFC 8546, la réduction des protocoles applicatifs à HTTP, etc.

DoH (DNS sur HTTPS) va-t-il changer la répartition du pouvoir entre les acteurs de l'Internet ?

Le protocole DoH (DNS-sur-HTTPS) est normalisé dans le RFC 8484. Le but de DoH est d'avoir des requêtes DNS (résolution de noms de domaine) privées (ne pouvant pas être écoutées par un tiers) et pas modifiables (par exemple par un censeur). Mais des polémiques ont éclaté sur les déploiements actuels, qui se font uniquement vers les serveurs DNS de quelques GAFA. Vaut-il mieux être surveillé par Orange ou par Google ? On explorera les détails de DoH, la relation subtile entre les protocoles, avec les choix qu'ils impliquent, et leurs conséquences politiques, et on examinera dans quelles conditions on peut éviter de tomber de Charybde en Scylla, et limiter les problèmes causés par le FAI sans avoir les mêmes problèmes plus loin, avec un autre acteur.

Daniel Stenberg, Stéphane Bortzmeyer and Bert Hubert will discuss the changing DNS privacy landscape, including topics such as DoH, DoT. Moderated by Jan-Piet Mens.

Other people: Daniel Stenberg Bert Hubert Jan-Piet Mens

Les discussions politiques au sujet de l'Internet se limitent souvent à trois ou quatre GAFA, la seule chose que connaissent certains commentateurs. Pourtant, l'infrastructure de l'Internet pose également plein de questions politiques essentielles. La technique est-elle neutre ? Est-ce que les réseaux numériques posent des problèmes politiques particuliers ? Le pair à pair va t-il sauver la neutralité du réseau ? Pour la diversité linguistique, faut-il traduire les méthodes GET et POST de HTTP ? Le protocole BGP est-il de gauche ? L'Internet est-il favorable ou défavorable aux droits humains (au passage, le 10 décembre, ce sera le 70e anniversaire de la Déclaration universelle des droits humains) ? Et toutes ces questions peuvent-elles être expliquées à M. et Mme Michu ? L·e·a citoyen·ne de base doit-il·elle et peut-il·elle comprendre l'Internet ? Ou bien est-ce inutile et impossible, et il vaut mieux laisser ces questions aux gens sérieux ?

The DNS privacy project started in november 2013 at the IETF meeting in Vancouver, following Snowden's revelations. Where are we today? We have a problem statement (RFC 7626), standard solutions (QNAME minimisation, DNS over TLS), running code (such as the getdns library) and actual deployments (such as the Quad9 public resolver). The talk will examine the current state of the project. It is intended for people who have a general knowledge of DNS, but you don't need to be an expert.

Unlike HTTP and Web privacy, the issue of privacy for DNS users was never a hot topic. There are no specific rules or regulations about it, and the typical Data Protection Agency, GDPR or not GDPR, is not too interested in the subject. But DNS traffic can be very revealing and has already been used to identify things such as malware communicating with a C&C. If DNS surveillance can be done for the good, it can certainly also be done for evil purposes.

This is what motivated the Internet Engineering Task Force to start a work at the Vancouver meeting in november 2013, with a more official start at the London meeting in march 2014. The project followed the classical steps: describing the problem, the threat model, the actual rissk (this is now documented in RFC 7626), then trying to find solutions. While many geeks, when asked about privacy, immediately scream "encryption", privacy actually requires TWO things: encryption to protect against third parties, AND data minimisation, to protect you against the servers you talk to. Hence the development of two solutions, encryption with TLS (RFC 7858) and QNAME minimisation (RFC 7816).

There is also running code. The Unbound DNS resolver already knows how to encrypt (upstream and downstream), and can also perform QNAME minimisation, like the Knot resolver. The excellent getdns library also speaks DNS-over-TLS, allowing things like a monitoring plugin to monitor your DNS-over-TLS servers. Android has now DNS-over-TLS in its code base.

And there are some public deployments with this technology. The OpenWrt router Turris Omnia already ships, by default, with QNAME minimisation enabled. The Quad9 public DNS resolver accepts DNS-over-TLS.

What can we expect in the future? There are some projects to allow encryption between resolver and authoritative server (RFC 7858 only cobvers the stub-to-resolver case), to add padding to more TLS requests (getdns and Knot already do it), but most of the work will probably be on the code and deployment.