RFC 9276, l'Afnic adopte le régime sans sel

En substance, celui-ci nous avertissait que notre configuration DNSSEC n’était plus conforme aux standards en vigueur et que nous prenions le risque que les TLD que nous opérons ne soient plus validés correctement par les services de résolution DNS.

En voici un extrait :

Quel est donc ce RFC dont il est fait mention dans ce message et fallait-il s’inquiéter d’éventuelles perturbations du service de résolution dans un avenir proche ? Ce sont ces 2 interrogations auxquelles nous allons tenter de répondre ici.

Nous nous proposons aussi de faire un état des lieux des pratiques actuellement en cours chez nos homologues registres ainsi que dans la zone .fr, et présenter les évolutions que nous avions prévu de réaliser prochainement.

Présentation du RFC 9276 (Guidance for NSEC3 Parameter Settings)

Ce document, publié au mois d’août, et qui vient s’ajouter à la trentaine de RFC traitant directement de DNSSEC, propose de nouvelles recommandations sur le paramétrage des zones signées ayant opté pour la technologie NSEC3. Bien que le mail de l’ICANN nous ait rappelé qu’il ne fallait pas oublier de traiter ce sujet, nous n’avons pas découvert ce RFC ni ces recommandations à cette occasion. En effet, le sujet revient régulièrement dans les discussions dans les groupes techniques des instances auxquelles nous participons (DNS-OARC, IETF, …) et sa formalisation au sein d’un « Internet Draft » date de plus d’un an déjà. Mais concrètement, que dit ce RFC 9276 ?

Lorsque l’on signe une zone dans le cadre de DNSSEC, 2 techniques s’offrent à nous pour régler le problème de preuve de non-existence, NSEC (RFC 4034) ou NSEC3 (RFC 5155). Normalisé quelques années après NSEC, NSEC3 est une réponse à la principale critique à laquelle le premier devait faire face, à savoir qu’il est extrêmement facile d’énumérer le contenu d’une zone. Aujourd’hui, avec l’open data cela peut sembler un combat d’une autre époque mais au début des années 2000 c’était un sujet auquel de nombreux registres de noms de domaine étaient sensibles.

Si aujourd’hui, cet aspect n’est plus aussi crucial, pourquoi utiliser malgré tout NSEC3 ? La réponse se trouve dans la possibilité, qui n’existe pas avec NSEC, d’activer l’option « opt-out ». Celle-ci permet de ne pas signer l’intégralité des enregistrements de la zone mais uniquement ceux qui en ont besoin. La différence en termes de ressources CPU, stockage, bande passante est considérable pour les zones qui ne contiennent qu’une minorité d’enregistrements à signer. C’est principalement cette fonctionnalité qui fait que NSEC3 est privilégié par de nombreux acteurs de notre industrie, malgré sa complexité, aux dépends de NSEC.

Ce qu’il faut savoir sur NSEC3, et c’est l’objet de ce document, c’est que là où NSEC utilise un nom de domaine en clair dans l’enregistrement pour réaliser la preuve de non existence, NSEC3 utilise un résumé cryptographique. Pour complexifier encore un peu le process, le calcul de ce résumé dépend de plusieurs paramètres pour lesquels le RFC 9276 propose des valeurs à privilégier.

Le nombre d’itérations

La méthode de calcul du résumé cryptographique permet de répéter l’opération plusieurs fois dans l’objectif de rendre plus difficile les attaques par dictionnaire (Une attaque par dictionnaire consiste à essayer systématiquement et automatiquement tous les noms que l’on pense intéressants). Un paramètre permet de choisir le nombre d’itérations supplémentaires qui seront réalisées, de fait, même si la valeur de celui-ci est à 0, il y a au moins un calcul réalisé.

L’usage de NSEC3 depuis sa mise en œuvre ainsi que des travaux récents semblent indiquer que les bénéfices d’un nombre d’itérations au-delà de la première ne sont pas suffisants pour justifier les coûts de traitement supplémentaires que cela induit lors de la génération de ces enregistrements, lors de chaque réponse NXDOMAIN par le serveur faisant autorité ou lors de la validation DNSSEC au cœur des résolveurs.

Les auteurs de ce RFC conseillent donc de mettre ce paramètre à 0.

Le sel

En plus du nombre d’itérations, il est possible de rajouter un sel lors du calcul du résumé cryptographique. Toujours dans le but de rendre plus complexe une attaque par dictionnaire. Mais dans le cas présent, sachant que lors du calcul c’est le nom de domaine complet (FQDN) qui est utilisé, cela implique qu’un attaquant est déjà obligé d’avoir un dictionnaire par zone.

L’utilité d’ajouter un sel supplémentaire, surtout si celui-ci n’est « jamais » changé (un changement oblige à re-signer complètement une zone) est donc contestable.

Les auteurs de ce RFC conseillent donc de ne pas utiliser de sel.

Recommandations

La mise en œuvre de ces recommandations s’adresse à 2 types de populations. Dans un premier temps les opérateurs qui publient des fichiers de zone. Pour ceux-ci, il est vivement conseillé de réfléchir aux avantages de NSEC3 par rapport à NSEC et de ne l’utiliser que si NSEC ne répond pas à leurs besoins. Dans l’éventualité où c’est NSEC3 qui serait choisi il est recommandé de ne pas utiliser de sel ni d’itérations supplémentaires (nous verrons par la suite comment ces conseils sont pris en compte dans la réalité).

Dans un second temps, les résolveurs réalisant de la validation DNSSEC, eux, devraient petit à petit n’accepter que des valeurs « raisonnables » de ces 2 paramètres (pas de calendrier existant à ce stade, mais le sujet étant sensible, il est probable qu’au cours des prochains mois, ce point soit discuté et donc éclairci). Déjà, depuis l’année dernière, la majorité des solutions logicielles utilisées (Bind, Knot, Unbound, PowerDNS, …) ont mis en place des limites comme valeurs par défaut pour ces paramètres. Ces limites ne sont pas aussi draconiennes que celles proposées ici et le fait que ce soit disponible n’indique pas que ce soient ces dernières versions qui sont déployées et que ces valeurs par défaut sont conservées, mais, un changement est en marche. En cas de paramètres « hors limite », ces serveurs pourraient par exemple décider de retourner une réponse de type SERVFAIL aux clients lors du traitement des enregistrements de type NSEC3. C’est ce point particulier (paragraphe 3.2 du RFC 9276) qui pourrait avoir des conséquences opérationnelles pour les zones qui ne se conformeraient pas à ces recommandations.

Faut-il pour autant s’en inquiéter ? La réponse est oui (un peu)… mais pas immédiatement. En effet, même si rien n’empêche un opérateur de ce type de résolveur d’appliquer à la lettre les recommandations faites par les 2 auteurs de ce RFC, il est très peu probable que cela se fasse de manière unilatérale. D’autant que le RFC 8914 qui est conseillé pour répondre dans certains cas de figures n’est pas encore complètement mis en œuvre chez les fournisseurs de solutions DNS. De plus il faudrait que ceux-ci s’accordent pour proposer une action coordonnée, comme cela a pu être fait par le passé lors des « DNS Flag Day ».

Ceci dit, peut-être est-il temps de vérifier ces paramètres dans vos zones afin d’utiliser des valeurs dites « raisonnables ». Nous verrons d’ailleurs par la suite que c’est le cas dans la grande majorité des cas mais que quelques zones utilisent malgré tout des valeurs inhabituelles qu’il conviendrait de modifier.

Etat des lieux de la racine et des domaines de tête

Nous avons réalisé une analyse ce mois d’octobre sur l’ensemble des noms de domaine de premier niveau.

Sur les 1487 TLD étudiés, l’écrasante majorité, soit 1363, sont signés. Plus de 97% de ces zones signées ont opté pour NSEC3. Le choix de l’opt-out a été fait par 86% de celles-ci. Concernant le nombre d’itérations supplémentaires, même si le maximum est de 25 pour quelques rares TLDs, 40% utilisent le paramètre recommandé de 0, sachant que de toute façon 99% ont un nombre d’itérations supplémentaires de 10 ou moins. Quant au sel, pour 99% des zones, sa taille n’excède pas 8 octets, 40% ayant déjà adopté le régime sans sel préconisé par nos 2 auteurs. Notons que si l’on regarde un peu plus en détails, à savoir uniquement les ccTLD, cette adoption est un peu plus faible, 23% au lieu de 40%.

Sans surprise les zones que nous opérons correspondent au portrait type du TLD. Toutes celles-ci sont signées, utilisent l’opt-out et NSEC3, avec un sel de 4 octets et une seule itération supplémentaire.

Etat des lieux pour la zone .fr

Sachant que nous connaissons de manière exhaustive la liste des zones signées pour ce TLD, nous avons pu réaliser une analyse sur les quelques 750 000 zones concernées. Le profil qu’il en ressort est un peu différent de celui des TLD.

En effet, même si avec 89%, NSEC3 reste le choix prioritaire de ces zones, l’opt-out est très minoritaire, à savoir, moins de 1%. Pour le nombre d’itérations, seuls 1,5% utilisent la valeur recommandée de 0. Si la quasi-totalité des zones ont un nombre d’itérations supplémentaires de 10 ou moins, plusieurs centaines d’autres sont au-delà de 100 (le maximum étant de 200). Pour ces dernières, il pourrait être urgent de changer puisque certains éditeurs de logiciels ont déjà fixé à 150 le nombre maximum d’itérations qu’ils acceptent (valeur modifiable, mais c’est la valeur par défaut). Pour finir, comme pour les TLD, même si on peut trouver des sels de 64 octets, la très grande majorité est d’une taille inférieure ou égale à 8 octets.

Changements à venir, ce que nous avons décidé

Comme planifié depuis quelques mois, dans les prochaines semaines, l’AFNIC va modifier le paramétrage des zones opérées pour supprimer les sels et ne pas ajouter d’itérations supplémentaires dans le calcul du résumé cryptographique.

Nous conservons toutefois NSEC3 et l’opt-out. En effet avec cette option, la zone .fr contient 14 millions d’enregistrements ; sans, elle en contiendrait 10 millions de plus, passant ainsi de 650 Mo à 1,4Go (l’augmentation en taille n’est pas proportionnelle car les enregistrements supplémentaires, NSEC3, RRSIG sont de taille conséquente).

Conclusion

Bien que ce type de RFC n’ait pas de valeur normative, il décrit la manière dont devrait être mis en œuvre NSEC3. À ce titre, il sera progressivement intégré dans les différentes solutions DNS utilisées par les résolveurs validant. L’Afnic, de son côté, va continuer à suivre les travaux sur ce sujet et prendre les mesures nécessaires pour informer sa communauté si d’aventure nous constations des zones impactées par les changements à venir. Dès à présent, nous conseillons fortement aux gestionnaires de zones affichant des paramètres très éloignés des usages de la majorité des acteurs du secteur de revoir ceux-ci afin d’éviter les mauvaises surprises.