ECDSA : la pièce manquante de DNSSEC
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'elle soit actuellement utilisée 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.
Amplification des attaques DDoS
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 importante 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.
Taille de la réponse ECDSA par rapport à RSA
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.
Inconvénients de ECDSA
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.
Conclusion
Toute 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 le protocole DNSSEC pour toutes leurs capacités.Les serveurs d'inscription n'acceptent pas tous DNSSEC, et il n'est pas anodin d'en ajouter la prise en charge.Ils doivent permettre à leurs utilisateurs de télécharger des enregistrements DS, qui doivent à leur tour être téléchargés sur le registre par le serveur d'inscription.Nous nous efforçons d'automatiser la procédure afin que les personnes inscrites n'aient même pas besoin de télécharger l'enregistrement DS, mais cela nécessite toujours l'intervention du serveur d'inscription.
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.
La solution Cloudflare est facile à configurer
Configurez un domaine en moins de 5 minutes. Conservez votre fournisseur d'hébergement. Aucune modification du code n'est requise.
Des millions de propriétés Internet nous font confiance
