Le protocole de transport QUIC (couche 4 du modèle OSI) vient d’être normalisé, sous la forme de plusieurs RFC. QUIC, déjà largement déployé, peut changer pas mal de choses sur le fonctionnement de l’Internet, en remplaçant, au moins partiellement, TCP. C’est quoi, QUIC, et à quoi ça sert ? 
Lorsque l’on essaie de convaincre des personnes de quitter les vilains réseaux sociaux centralisés des GAFAM comme Facebook ou YouTube, censeurs et piqueurs de données personnelles, l’objection la plus courante qui est faite est : « Mais, tous mes amis sont sur Facebook, YouTube, Google+ [non, je rigole] et Instagram. Donc, si je pars, je me retrouve seul. » L’idéal serait que tout le monde parte en même temps des GAFAM pour aller vers des réseaux sociaux libres et décentralisés, mais cela semble peu réaliste.
Une solution serait alors de contraindre par la loi les acteurs (tous états‐uniens). Mais serait‐ce efficace ?
Le résolveur DNS Quad9 (prononcer « quoi de neuf » en français) a été annoncé aujourd’hui. C’est un résolveur DNS public, mais dont l’originalité est d’être accessible de manière sécurisée, avec TLS (DNS sur TLS est décrit dans le RFC 7858).
Alors, le lectorat de LinuxFr.org, étant très au fait du sujet, va dire « mais des résolveurs DNS publics, il y en a plein ! Pourquoi un de plus ? ». Le plus connu est Google Public DNS, mais il en existe beaucoup d’autres, avec des politiques et des caractéristiques techniques diverses. Notamment, tous (à l’exception de Cisco OpenDNS) sont non sécurisés : le lien entre vous et le résolveur est en clair, tout le monde peut écouter, et il n’est pas authentifié, donc vous croyez parler à Google Public DNS mais, en fait, vous parlez au tricheur que votre FAI a annoncé dans ses réseaux locaux.
Joyce Reynolds vient de mourir, de maladie. Elle était l’auteure de nombreux RFC (demande de commentaires), dont ceux sur le protocole telnet. Elle était aussi co-éditrice des RFC à la grande époque (celle de Jon Postel). Comme elle signait « J. K Reynolds », des tas de gens qui cherchaient à contacter « l’auteur de telnet » étaient surpris en la voyant « mais non, je cherche un technicien ». Elle avait aussi travaillé sur plein d’autres trucs des débuts de l’Internet (comme le TLD .us) et de l’IETF.
La demande de commentaires (RFC) 7626, « DNS Privacy Considerations », a été publiée fin août par l'IETF (entité qui élabore les standards d'Internet). Elle est issue des travaux du « groupe de travail IETF sur DNS et vie privée » évoqué précédemment. Ce document se focalise sur les risques encourus par les usagers pour leur vie privée, dans l'usage actuel des services de résolutions de noms.
Les groupes de travail IETF sont maintenant bien occupés aux futures solutions (minimisation des données envoyées et chiffrement).
Le risque d'une surveillance particulière pour un titulaire de zone est discuté via les RFC 5936 & 5155. Les risques autres que ceux concernant la vie privée (comme du cache poisoning) sont hors-sujet ici. Nous considérons ici les risques pour la vie privée d'une surveillance générale ou plus précise.
« Ce[tte] RFC est en fait à la croisée de deux activités. L'une d'elles consiste à documenter les problèmes de vie privée, souvent ignorés jusqu'à présent dans les RFC. Cette activité est symbolisée par le RFC 6973 (…). Et la seconde activité qui a donné naissance à ce RFC est le projet d'améliorer effectivement la protection de la vie privée des utilisateurs du DNS, en marchant sur deux jambes : minimiser les données envoyées (…) et les rendre plus résistantes à l'écoute, via le chiffrement. ».
Des tas de gens et d’organisations ont été secoués par les révélations du héros Edward Snowden concernant l’ampleur de l’espionnage réalisé par la NSA (et, certainement, par bien d’autres organisations). Bien sûr, les experts en sécurité savaient depuis longtemps, mais ils avaient le plus grand mal à se faire entendre ; les dirigeants et les utilisateurs préféraient se moquer de ces experts, en les qualifiant de paranoïaques. Les révélations de Snowden ont montré que les paranoïaques ne l’étaient en fait pas assez, et que l’ampleur de l’espionnage dépassait les pires prévisions.
Cela a nécessité des changements de direction à pas mal d’endroits. Par exemple, l’IETF, l’organisation qui établit les normes techniques de l’Internet. Traditionnellement, elle se préoccupait peu de vie privée, parfois considérée comme « un problème politique, ce n’est pas pour nous ». Cela a changé dans les dernières années mais les révélations Snowden ont mené à une brusque accélération. À la réunion de l’IETF à Vancouver, du 3 au 8 novembre, on a donc beaucoup parlé de vie privée. Tous les groupes de travail avaient consacré du temps à un examen de leurs protocoles, sous l’angle de la protection de la vie privée. Et la plénière technique du 6 novembre, avec Bruce Schneier en invité vedette, avait été entièrement consacrée à cette question. La décision la plus spectaculaire a été l’accord très large de l’IETF (par le biais du fameux « hum », l’IETF n’ayant pas de procédures de vote) pour se lancer à fond dans cette voie.
NdM : merci à Stéphane Bortzmeyer pour son journal.
L'ICANN avait annoncé le programme de création des nouveaux TLD (Top-Level Domain, nom de domaine de tête comme .fr ou .net) à sa réunion de Paris en juin 2008. Cinq ans après, les quatre premiers TLD de la série viennent d'arriver dans la racine du DNS. Tous les quatre sont des IDN (noms de domaine en Unicode) :
Un Bureau d'Enregistrement rappelle que l'enregistrement dans ces nouveaux TLD n'est pas ouvert
Petit rappel de gouvernance Internet : l'ICANN n'a aucun pouvoir sur la racine du DNS. C'est le gouvernement des États-Unis, via l'agence NTIA (National Telecommunications and Information Administration), qui donne les autorisations et Verisign, l'opérateur technique, qui les met en œuvre, comme Verisign n'a pas manqué malicieusement de le rappeler sur son Twitter.
NdM : merci à Stephane Bortzmeyer pour son journal.
Ce RFC (un appel à commentaires sur des aspects techniques) met officiellement fin à une amusante tradition, qui faisait l'un des charmes des protocoles TCP/IP mais qui, en pratique, a causé quelques ennuis, justifiant son abandon. Cette tradition concernait le nommage des paramètres dans les protocoles. Normalement, ces noms étaient enregistrés à l'IANA (Internet Assigned Numbers Authority) pour éviter des collisions (par exemple, il ne doit y avoir qu'un seul champ nommé User-Agent: dans une requête HTTP).
NdM : le protocole SIP est un cas plus exotique avec ces en-têtes préfixés « P- » et la possibilité d'avoir plusieurs fois la même, comme Via: par exemple. On pourrait poursuivre l'analogie avec les préfixes CSS des navigateurs, comme -moz- ou -webkit-(ou encore -o- et -ms-), voir l'appel pour le web ouvert.
Comme cet enregistrement nécessitait une procédure, parfois lente et lourde, cela contrariait les gens qui voulaient expérimenter avec une nouvelle idée, qui impliquait un nouveau paramètre. L'habitude, avec l'appui de quelques RFC, s'était donc répandue de donner à ces paramètres expérimentaux, non officiels, un nom commençant par la lettre X suivie d'un tiret. Cette pratique a rencontré plusieurs problèmes et est donc désormais fortement déconseillée.
NdM : merci à Stephane Bortzmeyer pour son journal.