Le procotole DNSSEC est un sujet complexe, et la disponibilité de plusieurs algorithmes de sécurité standard pour la signature des enregistrements DNS, définis par l'IANA, rend les choses encore plus confuses. L'algorithme 13 est une variante de l'algorithme de signature numérique à courbes elliptiques (ECDSA). Bien qu'il soit actuellement utilisé par moins de 0,01 % des domaines, nous tenons à préciser que ECDSA nous a permis d'éliminer les deux derniers obstacles à l'adoption généralisée des DNSSEC à savoir l'énumération des zones et l'amplification des attaques DDoS.
Cet article s'articule autour des points suivants :
Copier le lien de l'article
Le procotole DNSSEC est un sujet complexe, et la disponibilité de plusieurs algorithmes de sécurité standard pour la signature des enregistrements DNS, définis par l'IANA, rend les choses encore plus confuses. L'algorithme 13 est une variante de l'algorithme de signature numérique à courbes elliptiques (ECDSA). Bien qu'il soit actuellement utilisé par moins de 0,01 % des domaines, nous tenons à préciser que ECDSA nous a permis d'éliminer les deux derniers obstacles à l'adoption généralisée des DNSSEC à savoir l'énumération des zones et l'amplification des attaques DDoS.
La signature en direct empêche l'énumération de zones et cela n'est efficace sur le plan informatique que grâce à la génération rapide de signature ECDSA. Les courbes elliptiques produisent également des clés et des signatures beaucoup plus petites que leurs équivalents RSA, ce qui signifie que les réponses aux requêtes DNS sont plus petites. Cela réduit considérablement le facteur d'amplification des attaques DDoS basées sur le DNS.
DNSSEC introduit le déni d'existence authentifié via les enregistrements NSEC et NSEC3. Cependant, comme nous l'avons évoqué dans Complexités et considérations relatives au DNSSEC, NSEC et NSEC3 permettent tous les deux aux attaquants de parcourir la zone. La solution est une technique astucieuse
appelée « pieux mensonges DNSSEC (DNSSEC white lies) » (décrite dans les RFC 4470 et 4471), mais elle ne peut être mise en œuvre que si les enregistrements DNSSEC sont signés à la volée.
RSA est l'algorithme de signature le plus répandu dans DNSSEC, en partie parce que c'est le seul algorithme obligatoire défini par le protocole. Malheureusement, la signature en direct avec RSA est d'un coût prohibitif.
Avec ECDSA, les gains de performances sont spectaculaires. Une signature gérée avec ECDSA exige 10 fois moins de calculs qu'une signature RSA comparable. Cela rend la signature en direct (et les pieux mensonges DNSSEC) réalisable, même à grande échelle.
Pendant la mise en œuvre de notre version bêta du DNSSEC (avec moins de 1 000 domaines signés), Cloudflare a répondu à des dizaines de milliers de requêtes DNSSEC par seconde. Cela représente plus d'un milliard de requêtes par jour, et nous signons tous les enregistrements RRSIG nécessaires à la volée. Le fait de disposer d'un algorithme de signature 10 fois plus rapide que RSA marque une grande différence lorsqu'il s'agit de charger sur nos serveurs DNSSEC. Lorsque nous avons commencé à travailler avec ECDSA, notre mise en œuvre d'OpenSSL était en langage Go. Compte tenu de toutes les signatures que nous effectuons, l'optimisation de la génération de signatures était une priorité absolue. Nous avons donc réécrit la mise en œuvre d'ECDSA en langage assembleur de bas niveau, et elle est maintenant 20 fois plus rapide qu'elle ne l'était en Go. Ce code est open source et sera intégré dans Go 1.7 afin que l'ensemble de la communauté cryptographique puisse bénéficier de nos optimisations. En savoir plus
Cloudflare est le plus grand fournisseur de DNS géré au monde. Ce que nous cherchons absolument à éviter, c'est que nos serveurs DNSSEC deviennent vecteurs d'amplification pour les attaques par déni de service distribué (DDoS). Chaque fois que vous demandez un enregistrement à un serveur DNSSEC, celui-ci renvoie également la signature associée à cet enregistrement, ainsi que la clé publique utilisée pour vérifier cette signature. Cela représente potentiellement un grand nombre d'informations.
La taille des réponses aux requêtes DNSSEC doit être réduite au maximum, c'est une exigence majeure pour empêcher l'abus de notre infrastructure DNS par des attaquants potentiels. La petite taille des clés et des signatures ECDSA va dans ce sens.
Pour obtenir une sécurité de 128 bits avec ECDSA, il faut une clé de 256 bits, alors qu'une clé RSA comparable serait de 3072 bits. C'est un facteur d'amplification par 12 à portée de clavier. Pour en savoir plus sur les raisons pour lesquelles les clés cryptographiques ont des tailles différentes, consultez cet article du blog.
Mais, la plupart des clés RSA ne sont pas de 3072 bits, donc un facteur d'amplification par 12 n'est peut-être pas le chiffre le plus réaliste. Examinons le pire scénario concret en matière d'amplification des attaques DDoS, à savoir une réponse négative (enregistrement NSEC). Pour un domaine protégé par Cloudflare (qui utilise des signatures ECDSA et des pieux mensonges DNSSEC), la réponse DNSSEC typique est de 377 octets. Comparez cela à 1075 octets pour un domaine n'utilisant pas les pieux mensonges ECDSA ou DNSSEC.
Si l'on considère que toutes les autres mises en œuvre DNSSEC à grande échelle reposent sur des signatures RSA, il est peu probable qu'un attaquant utilise notre infrastructure DNSSEC comme vecteur d'attaque DDoS.
ECDSA apporte une solution à des problèmes majeurs du protocole DNSSEC, mais il est à peine exploité par la communauté DNSSEC mondiale. Nous avons examiné rapidement l'adoption de ECDSA dans la zone DNS racine et le million d'Alexa.
Nous avons d'abord examiné la zone DNS racine pour déterminer quels sont les algorithmes DNSSEC utilisés par les domaines de premier niveau. Le tableau suivant affiche les algorithmes de sécurité spécifiés par les enregistrements DS dans le fichier de la zone racine :
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
Nous avons effectué une analyse similaire pour le million d'Alexa, qui nous donne un échantillon représentatif du trafic Internet mondial :
| Algorithme | Nombre de fiches DS signées |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (Courbe ECDSA P-256 avec SHA-256) | 23 |
La révélation la plus frappante est que sur les 1 000 000 de sites Web, seuls 15 643 permettent l'utilisation de DNSSEC sur toutes leurs capacités. Sur ces 1,5%, seules 23 zones sont signées avec l'Algorithme 13. Et plus de la moitié de ces zones Algorithm 13 se trouvent derrière le réseau Cloudflare. Cela signifie qu'il y a moins d'une douzaine de zones sur le million d'Alexa qui utilisent ECDSA en dehors de Cloudflare. Cela confirme les conclusions de Roland van Rijswijk-Deij et coll. selon lesquelles 99,99 % des domaines qui sont signés en .com, .net, et .org utilisent RSA.
Alors, pourquoi l'utilisation de l'algorithme 13 est-elle si faible, surtout si l'on considère qu'il résout des problèmes aussi importants dans DNSSEC ? Le chiffrement RSA a été introduit avec le protocole DNSSEC dès les débuts de ce dernier. ECDSA est un nouvel algorithme cryptographique, et les résolveurs, les serveurs d'inscription et les registres sont encore en train de s'adapter.
ECDSA n'est pas sans inconvénient. Selon Roland van Rijswijk-Deij et coll., seuls 80 % des résolveurs prennent en charge la validation ECDSA. Ce nombre est en augmentation, mais cela signifie que si nous basculions l'ensemble de l'Internet DNSSEC sur ECDSA dès maintenant, la validation DNSSEC échouerait pour des millions d'utilisateurs d'Internet chaque jour, ce qui aurait pour conséquence le renvoi d'enregistrements DNS non vérifiés.
Qui plus est, si la création de la signature ECDSA est plus rapide que celle de RSA, la validation de la signature est en fait beaucoup plus lente. Roland van Rijswijk-Deij et coll. ont montré que, même avec les optimisations d'ECDSA que nous avons apportées à OpenSSL, ECDSA est toujours 6,6 fois plus lent que le RSA 1024 bits (qui est l'algorithme le plus couramment utilisé pour les clés de signature de zone). Le problème est à prendre au sérieux car la surcharge des résolveurs DNS pourrait potentiellement ralentir l'ensemble de l'Internet.
Une discussion autour de l'algorithme 13 se doit de préciser une réserve très importante: seules 1,5 % des propriétés web prennent en charge les DNSSEC pour n'importe laquelle de leurs capacités. Tous les serveurs d'inscription n'acceptent pas le protocole DNSSEC. Il n'est donc pas anodin d'en ajouter la prise en charge. Ces derniers doivent permettre à leurs utilisateurs de télécharger des enregistrements DS, qui doivent à leur tour être importés sur le registre par le bureau d'enregistrement. Nous nous efforçons d'automatiser la procédure afin que le déclarant n'ait même pas besoin d'importer l'enregistrement DS. Toutefois, cette opération nécessite toujours une intervention du bureau d'enregistrement.
La bonne nouvelle, c'est que nous allons dans la bonne direction. Au cours des 12 derniers mois, le protocole DNSSEC de manière générale a affiché une croissance décente. Et, dans les trois semaines qui ont séparé la sortie de la version bêta de DNSSEC pour le public et l'annonce de notre fonctionnalité Universal DNSSEC, Hover, OVH, Metaname, Internet.bs, et le registre .NZ ont ajouté la prise en charge de l'algorithme 13.
Nous pensons que DNSSEC est une technologie essentielle pour le web moderne et que ECDSA rend possible l'adoption du DNSSEC au niveau mondial. Nous espérons que les serveurs d'inscription et les registres, petits et grands, continueront à prendre en charge l'algorithme 13.