12. Security Considerations

12.1. Hashing Considerations

12.1.1. Dictionary Attacks

Les RR NSEC3 restent sensibles aux attaques par dictionnaire : l'attaquant récupère tous les RR NSEC3, calcule les hachages de tous les noms de domaine plausibles, les compare aux hachages trouvés dans les RR NSEC3 et énumère ainsi la zone. Ces attaques sont nettement plus coûteuses que l'énumération des RR NSEC d'origine ; elles pourraient aussi viser directement le serveur de noms par requêtes sur tous les noms plausibles, ce qui serait plus facile à détecter. Le coût de cette attaque hors ligne est réglable via le nombre d'itérations dans le RR NSEC3.

Les zones sont aussi exposées à une attaque par dictionnaire précalculé : une liste de hachages pour tous les noms plausibles est calculée une fois, puis les RR NSEC3 sont scrutés périodiquement et comparés aux hachages précalculés. Changer le sel régulièrement permet de contrer cette attaque.

Le sel DEVRAIT faire au moins 64 bits et être imprévisible, afin que l'attaquant ne puisse pas anticiper sa valeur et calculer le prochain ensemble de dictionnaires avant publication de la zone.

12.1.2. Collisions

Des collisions de hachage entre le QNAME et le nom de titulaire d'un RR NSEC3 peuvent survenir. Alors, il est impossible de prouver la non-existence du QNAME en collision. Avec SHA-1, cela reste hautement improbable (de l'ordre de 1 sur 2^160). DNSSEC repose déjà sur l'hypothèse que la fonction de hachage est résistante à la seconde préimage, car ces fonctions servent à générer et valider les signatures et les RR DS.

12.1.3. Transitioning to a New Hash Algorithm

Bien que les formats RR NSEC3 et NSEC3PARAM incluent un paramètre d'algorithme de hachage, ce document ne définit pas de mécanisme particulier pour passer en toute sécurité d'un algorithme de hachage NSEC3 à un autre. Lorsqu'un nouvel algorithme est spécifié pour NSEC3, un mécanisme de transition DOIT aussi être défini. Les seuls mécanismes de transition réalistes et acceptables pourront exiger un passage intermédiaire par un état non sécurisé, ou un état utilisant des enregistrements NSEC plutôt que NSEC3.

12.1.4. Using High Iteration Values

Comme les validateurs traitent les réponses contenant des RR NSEC3 à nombre d'itérations élevé comme non sécurisées, la présence d'un seul RR NSEC3 signé à valeur d'itérations élevée dans une zone offre aux attaquants une possible attaque par déclassement.

L'attaque consiste à retirer les RR NSEC3 existants de la réponse et à y substituer ou ajouter un (ou plusieurs) RR NSEC3 à itérations élevées. Les validateurs traiteront alors la réponse comme non sécurisée. Elle n'est efficace que si toutes les conditions suivantes sont réunies :

Au moins un RR NSEC3 signé à itérations élevées est présent dans la zone.
L'attaquant peut accéder à un ou plusieurs de ces RR NSEC3. C'est trivialement vrai lorsque ces RR sont renvoyés dans des réponses courantes, mais aussi si l'attaquant peut lire la zone via AXFR, IXFR ou autre moyen.

Un nombre d'itérations élevé crée en outre une possibilité supplémentaire de déni de service contre les serveurs, qui doivent calculer plusieurs hachages par réponse négative ou joker.

12.2. Opt-Out Considerations

Le drapeau Opt-Out (O) permet l'existence de noms non signés, sous forme de délégations vers des zones non signées, au sein d'une zone par ailleurs signée. Tous les noms non signés sont par définition non sécurisés ; leur validité ou leur existence ne peut être prouvée cryptographiquement.

En général :

Les enregistrements de ressource portant des noms non signés (existants ou non) subissent les mêmes vulnérabilités que les RR d'une zone non signée. Le détail figure dans [RFC3833] (notamment la section 2.3, « Name Chaining », et la section 2.6, « Authenticated Denial of Domain Names »).
Les RR portant des noms signés ont la même sécurité que l'on utilise Opt-Out ou non.

Avec ou sans Opt-Out, une délégation non sécurisée peut être modifiée par un attaquant sans être détectée. La principale différence de sécurité avec Opt-Out est donc la perte de la capacité à prouver l'existence ou la non-existence d'une délégation non sécurisée dans l'intervalle d'un RR NSEC3 Opt-Out.

En particulier, une entité malveillante peut insérer ou supprimer des RR à noms non signés. Il s'agit en général de RR NS, mais cela inclut aussi les extensions joker signées (le RR joker est signé, mais le nom étendu est un nom non signé).

Pouvoir ajouter une délégation équivaut fonctionnellement à pouvoir ajouter n'importe quel type de RR : l'attaquant forge une délégation vers un serveur de noms sous son contrôle et place les RR voulus au sommet de la sous-zone.

Même si ce problème peut être mineur dans certains cas, il ne faut pas le négliger à la légère. Il est donc fortement RECOMMANDÉ d'utiliser Opt-Out avec parcimonie. En particulier, les outils de signature de zone NE DEVRAIENT PAS activer Opt-Out par défaut, et PEUVENT choisir de ne pas le prendre en charge du tout.

12.3. Other Considerations

Parcourir les RR NSEC3 révèle le nombre total de RR de la zone (plus les non-terminaux vides) et les types présents. On peut atténuer cela en ajoutant des entrées factices, mais une borne supérieure reste toujours trouvable.