Annexe C. Considérations particulières

Les paragraphes suivants précisent certains comportements spécifiques et expliquent des considérations particulières pour les implémentations.

C.1. Salage (Salting)

Compléter les noms de propriétaires d'origine avec un sel avant de hacher augmente le coût d'un dictionnaire de valeurs de hachage pré-générées. Pour chaque bit de sel, le coût d'un dictionnaire pré-calculé double (car il doit y avoir une entrée pour chaque mot combiné à chaque valeur de sel possible). Le RR NSEC3 peut utiliser un sel d'au maximum 2040 bits (255 octets), multipliant le coût par 2^2040. Cela signifie qu'en pratique, un attaquant doit recalculer le dictionnaire chaque fois que le sel change.

L'inclusion d'un sel, quelle que soit sa taille, n'affecte pas le coût de construction des RR NSEC3. Elle augmente toutefois la taille du RR NSEC3.

Il DOIT exister au moins un ensemble complet de RR NSEC3 pour la zone utilisant la même valeur de sel.

Le sel DEVRAIT être changé périodiquement pour empêcher un pré-calcul à partir d'un sel unique. Il est RECOMMANDÉ de changer le sel à chaque resignature.

Notez qu'un résolveur peut alors voir des RR avec des sels différents pour la même zone. C'est sans conséquence, car chaque RR est autonome (c'est-à-dire qu'il dénie l'ensemble des noms de propriétaires dont les hachages, en utilisant le sel du RR NSEC3, tombent entre les deux hachages du RR NSEC3) ; seul le serveur a besoin d'un ensemble complet de RR NSEC3 avec le même sel pour pouvoir répondre à toute requête possible.

Il n'est pas interdit d'avoir des RR NSEC3 avec des sels différents au sein d'une même zone. Toutefois, pour que les serveurs faisant autorité puissent retrouver de manière cohérente les RR NSEC3 couvrants, le serveur faisant autorité DOIT choisir un seul jeu de paramètres (algorithme, sel et itérations) à utiliser lors de la sélection des RR NSEC3.

C.2. Collisions de hachage

Une collision de hachage se produit lorsque des messages différents ont la même valeur de hachage. Le nombre attendu de noms de domaine nécessaires pour avoir une probabilité de 1 sur 2 d'observer une collision unique est d'environ 2^(n/2) pour un hachage de longueur n bits (c'est-à-dire 2^80 pour SHA-1). Bien que cette probabilité soit extrêmement faible, les paragraphes suivants traitent de l'évitement des collisions et de l'évaluation des dommages possibles en cas d'attaque exploitant des collisions de hachage.

C.2.1. Éviter les collisions de hachage lors de la génération

Lors de la génération des RR NSEC3, les valeurs de hachage sont supposées uniques. Dans le cas (académique) où une collision se produirait, un sel alternatif DOIT être choisi et toutes les valeurs de hachage DOIVENT être régénérées.

C.2.2. Analyse de l'exigence de seconde préimage

Une fonction de hachage cryptographique possède une propriété de résistance à la seconde préimage. Cette propriété signifie qu'il est calculatoirement infaisable de trouver un autre message ayant la même valeur de hachage qu'un message donné, c'est-à-dire, étant donné une préimage X, de trouver une seconde préimage X' != X telle que hash(X) = hash(X'). Le facteur de travail pour trouver une seconde préimage est de l'ordre de 2^160 pour SHA-1. Pour monter une attaque exploitant un RR NSEC3 existant, un adversaire doit trouver une seconde préimage.

À supposer qu'un adversaire soit capable de monter une telle attaque extrême, le dommage réel est qu'un message de réponse peut être généré qui prétend qu'un certain QNAME (c'est-à-dire la seconde préimage) existe, alors qu'en réalité QNAME n'existe pas (un faux positif), ce qui amènera soit un résolveur sensible à la sécurité à interroger à nouveau pour le nom inexistant, soit à faire échouer la requête initiale. Notez que l'adversaire ne peut pas mener cette attaque sur un nom existant, mais uniquement sur un nom qu'il ne peut pas choisir et qui n'existe pas encore.