Le système GADS (GNU Alternative Domain System, une partie de GNUnet) est un système de nommage réparti, sans racine, et résistant à la censure. Il repose sur des noms donnés localement (et donc sans signification globale unique) et de la cryptographie pour sécuriser.
Il serait erroné de la comparer au #DNS (Domain Name System). Bien qu’il utilise certaines parties du DNS (comme les mêmes enregistrements - Resource Records) et qu’il a certaines fonctions en commun avec le DNS, GADS a un cahier des charges très différent. Ainsi, il met en objectif principal la résistance aux attaques légales (la censure) et, par contre, ne cherche pas à fournir des noms uniques (un nom GADS comme "Alice" a une signification qui dépend de l’endroit où on est).
Le principe de base est issu de #SDSI (Simple Distributed Security Infrastructure) : chacun peut nommer comme il veut des ressources (ces noms locaux sont des « pet names », comme ceux de l’ancien /etc/hosts). Et on peut déléguer des noms. Ainsi, Alice peut avoir des ressources nommées "bob" et "charlie" (noms qui n’ont de signification que pour elle) et les noms créés par Bob et Charlie sont accessibles à Alice. Si Bob a une ressource nommé "denise", Alice peut accéder à bob/denise. Si Charlie nomme la même ressource "girlfriend", le nom charlie/girlfriend marchera aussi, pour Alice (la syntaxe gros-boutienne que j’utilise est inspirée des noms de fichiers Unix et l’absence de / initial illustre bien le fait que tous les noms, dans ce système, sont relatifs).
GADS utilise, lui, la syntaxe petit-boutienne des noms de domaines, avec de pseudo-TLD, notamment .GADS. Ainsi, denise.bob.gads signifie, pour Alice, la ressource nommée "denise" créée par la ressource que j’ai nommée "bob". Pour un autre utilisateur de GADS, ce nom signifiera autre chose. (Rappel : bien que cela n’ait pas encore été démontré mathématiquement, il est largement considéré comme impossible d’avoir à la fois la sécurité, l’unicité des noms, des noms mémorisables et l’absence de hiérarchie).
Pour sécuriser le processus de résolution, GADS utilise la cryptographie. Chaque ressource a une clé avec partie publique et partie privée. La clé est générée localement (pas d’autorité de certification). Les enregistrements sont signés avec la clé privée. La clé publique sert pour la délégation. Pour que denise.bob.gads marche, Bob met la clé publique de Denise (après, on le suppose, des vérifications) dans ses enregistrements. On note qu’on ne choisit donc pas le nom sous lequel les autres vous désignent (voilà d’intéressantes perspectives juridiques si je fais pointer fournisseur-de-kadhafi.stephane.gads vers le site Web d’Amesys...)
Les clés publiques peuvent être aussi utilisées dans le pseudo-TLD .ZKEY, qui, lui, fournit des noms quasi-uniques (mais ni mémorisables, ni facilement résolvables).
Voilà pour le principe. On note qu’il existe des tas de détails à régler ensuite. D’abord, la résolution. Je n’ai pas étudié ce point en détail mais GADS ne semble pas avoir l’équivalent de la résolution récursive du DNS. Soit un nom est dans la base locale, soit on le cherche dans une #DHT commune (le système #R5N). Cette DHT est vulnérable aux attaques (par exemple de type Sybil).
Parmi les autres détails que traite GADS, il y a celui de la réversibilité (si Alice envoie un message à denise.bob.gads, Denise n’a pas forcément de nom pour joindre Alice en réponse) et celui des protocoles qui tiennent pour acquis l’existence de noms uniques (comme HTTP avec son en-tête Host :). À chaque fois, GADS a dû développer une solution (il est très rare, dans les projets de « nommage alternatif », de voir un tel souci du détail).
Les fanas de la gouvernance Internet noteront que GADS est en traind’étudier la possibilité de mettre ses pseudo-TLD (comme .GADS ou .ZKEY) dans le registre des TLD spéciaux <►http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml>.
Mon avis sur GADS ? Le système est bien conçu techniquement et est prometteur. Les auteurs sont des experts du pair-à-pair et ont bâti sur la vaste expérience existante dans ce domaine. Surtout, ils sont honnêtes : contrairement aux escrocs des racines alternatives, ou aux zozos comme Peter Sunde qui n’ont jamais compris le triangle de Zooko (l’impossibilité d’avoir à la fois mémorisabilité, sécurité et absence de hiérarchie), ils jouent cartes sur table dès le début, en disant franchement qu’ils renoncent à l’unicité des noms.
À noter que le résumé du DNS dans le mémoire de Schanzenbach contient plusieurs erreurs sérieuses. Par exemple, le schéma 2.3 est faux pour la résolution récursive (le texte est par contre correct). Et le vocabulaire est souvent flou (il dit parfois à tort que le DNS est centralisé et parfois qu’il est réparti).
La page officielle de GNUnet : <►https://gnunet.org> et celle de GADS <►https://gnunet.org/gns> Le code est en <►https://gnunet.org/gnunet-094>
Plus détaillé et plus récent, le mémoire de master de Martin Schanzenbach, consacré à GADS et à son implémentation : <►https://gnunet.org/schanzen2012thesis> et le PDF car il n’est pas facile à trouver <►https://gnunet.org/sites/default/files/schanzen2012msc.pdf>
L’article de Rivest sur SDSI, l’ancêtre immédiat de GADS : <►http://people.csail.mit.edu/rivest/sdsi10.html>
Mon article sur l’impossibilité d’avoir à la fois sécurité, unicité et non-hiérarchie : <►http://www.bortzmeyer.org/no-free-lunch.html>
#GADS #censure #pair-à-pair #GNUnet