Si vous êtes responsable d'une zone DNS, et que vous la testez régulièrement avec
des outils comme Zonemaster ou
DNSviz (ce que font tous les responsables
sérieux), vous avez peut-être eu des avertissements comme quoi vos
« paramètres NSEC3 » n'étaient pas ceux conseillés. C'est parce que
les recommandations en ce sens ont changé avec ce RFC. Lisez-le donc si vous
voulez comprendre les recommandations actuelles.
D'abord, un peu de contexte. Ce RFC concerne les zones qui sont
signées avec DNSSEC
et qui utilisent les enregistrements NSEC3 du
RFC 5155. Aujourd'hui, par exemple, c'est le
cas de .fr,
.com mais aussi de
bortzmeyer.org grâce à qui vous êtes arrivés
sur cet article. Mais ce n'est pas le cas de la racine des
noms de domaine, qui
utilise NSEC (RFC 4035). Pour comprendre la
dfifférence entre les deux, je vous renvoie à mon article sur le
RFC 5155.
Un exemple où Zonemaster proteste, sur
icann.org :
Ce RFC 5155 donnait des conseils de
sécurité cryptographiques qui, avec le
recul et l'expérience se sont avérés sous-optimaux. Ce nouveau RFC 9276 les modifie donc et suggère fortement de
ne plus utiliser de sel, ni d'itérations
successives, dans le calcul des condensats pour
NSEC3.
Lorsqu'une zone est signée avec utilisation de NSEC3, elle
comprend un enregistrement de type NSEC3PARAM qui indique quatre
choses :
- L'algorithme de condensation utilisé
(presque toujours SHA-1, aujourd'hui, c'est
le
seul normalisé). Il n'est pas discuté ici (voir le RFC 8624 sur le choix des algorithmes).
- Les options, notamment celle nommée
opt-out et qui est un avantage souvent oublié
de NSEC3 par rapport à NSEC : la possibilité de ne pas avoir un
enregistrement NSEC3 par nom mais seulement par nom signé. C'est
un peu moins sûr (les noms non signés, typiquement les délégations
DNS, ne sont pas protégés) mais ça fait une grosse économie de
mémoire pour les zones qui comprennent beaucoup de délégations non
signées (et cela évite de passer trop de temps à modifier les
chaines NSEC3 dans des zones qui changent souvent). C'est
typiquement la cas des gros TLD et cela explique pourquoi
.fr ou
.com utilisent NSEC3,
même s'il n'y a pas de problème avec l'énumération des noms
(.fr distribue la
liste). (Notez que si l'option est à 0 dans le NSEC3PARAM,
cela ne signifie pas qu'il n'y a pas d'opt-out,
celui-ci est typiquement indiqué uniquement dans les
enregistrements NSEC3.)
- Le nombre d'itérations supplémentaires
(RFC 5155, sections 3.1.3 et 4.1.3)
faites lorsqu'on condense un nom.
- Le sel utilisé.
Voici par exemple l'enregistrement de
icann.org
en août 2024 :
% dig +short icann.org NSEC3PARAM
1 0 5 A4196F45E2097176
Utilisation de SHA-1 (le 1 est le code de SHA-1), pas
d'
opt-out (mais prudence, son utilisation n'est
pas obligatoirement signalée dans les options, voir plus haut), cinq
itérations supplémentaires (donc six au total) et un sel apparemment
aléatoire,
A4196F45E2097176.
La première recommandation du RFC concerne le nombre
d'itérations. Comme le sel, le but est de rendre plus difficile
l'utilisation de tables calculées à l'avance par un attaquant. Sans
sel et avec une seule itération, un attaquant qui a à l'avance
calculé tout un dictionnaire et sait donc que le condensat de
foobar est
8843d7f92416211de9ebb963ff4ce28125932878 pourra
donc facilement inverser le condensat dans un enregistrement
NSEC3. C'est pour cela que le RFC 5155
recommandait un nombre variable d'itérations, indiqué par
l'enregistrement NSEC3PARAM. Mais, en pratique, la protection contre
l'énumération n'est pas si solide que ça. Bien des noms peuvent être
devinés (www étant le plus évident mais il y a
aussi les mots d'un dictionnaire de la langue), d'autant plus qu'on
choisit en général un nom de domaine pour être simple
et facilement mémorisable. Et que ces noms se retrouvent à
plein d'endroits comme les journaux Certificate
Transparency (RFC 9162). L'opinion
d'aujourd'hui est que le jeu (la protection contre l'énumération)
n'en vaut pas la chandelle (le coût de signature
et de validation). Notez aussi une externalité négative : les résolveurs aussi devront effectuer ces
itérations et sont donc concernés. Bon, en prime, les techniques
modernes rendent la protection peu efficace de toute façon
(cf. « GPU-Based NSEC3 Hash
Breaking »). La recommandation du RFC
est donc de ne pas avoir d'itérations supplémentaires, donc de
mettre ce nombre à zéro.
Et la deuxième recommandation concerne le sel. Il y a dans NSEC3
un sel implicite, c'est le nom de domaine (RFC 5155, section 5). D'ailleurs, mon exemple de condensat de
foobar était faux, puisque j'avais omis cette
étape. Si on l'inclut, le sel supplémentaire indiqué dans
l'enregistrement NSEC3PARAM perd de son intérêt. En outre, en
pratique, on change rarement le sel (cela nécessite de modifier
toute la chaine NSEC3) ce qui diminue la protection qu'il offre. La
recommandation actuelle est donc de ne pas utiliser de sel (ce qui
se note avec un tiret, pas avec une chaine
vide).
Si on suit les recommandations du RFC, le NSEC3PARAM aura cette allure :
% dig +short fr NSEC3PARAM
1 0 0 -
Et un des NSEC3 sera du genre :
% dig nexistesurementpas.fr
qu7kmgn3e….fr. 594 IN NSEC3 1 1 0 - (
QU7MMK1…
NS DS RRSIG )
Notez aussi que le RFC recommande (section 3), avant de réfléchir
aux paramètres de NSEC3, de réfléchir à NSEC3 lui-même. Sur une
grosse zone de délégation, changeant souvent, comme
.fr, NSEC3 est tout à fait justifié en raison
des avantages de l'opt-out. Mais sur la zone DNS
typique d'une petite organisation, qui ne compte souvent que des
noms prévisibles (l'apex, www et
mail), NSEC3 peut avantageusement être remplacé
par NSEC, qui consomme moins de ressources. (NSEC3, ou d'ailleurs
les couvertures minimales du RFC 4470, peut, dans le
pire des cas, faciliter certaines attaques par déni de
service.)
Les recommandations précédentes s'appliquaient aux signeurs de
zone (côté serveurs
faisant autorité, donc). Mais la section 3 a aussi des
recommandations pour les résolveurs : compte-tenu du coût que
représente pour eux les itérations NSEC3, ils ont le droit d'imposer
un maximum, et de le diminuer petit à petit. Ces résolveurs peuvent
refuser de répondre (réponse SERVFAIL) ou bien traiter la zone come
n'étant pas signée (cf. section 6). Un nouveau code d'erreur étendu
(RFC 8914), le numéro
27, Unsupported NSEC3 iterations value, a
été réservé pour qu'ils puissent informer leurs clients.
Revenons aux serveurs
faisant autorité : le RFC précise aussi qu'un hébergeur DNS
devrait informer clairement ses utilisateurs des paramètres NSEC3
qu'il accepte. Il ne faudrait pas qu'on choisisse N itérations et
qu'on s'aperçoive au déploiement qu'un des secondaires n'accepte pas
d'en faire autant.
Aujourd'hui, la grande majorité des zones utilisant NSEC3 est
passée aux recommandations de ce RFC (comme par
exemple .fr en 2022). Notons que .org a
un sel mais pas d'itérations supplémentaires.
% dig +short org NSEC3PARAM
1 0 0 332539EE7F95C32A
Si vous utilisez OpenDNSSEC pour
automatiser les opérations DNSSEC sur vos zones, voici la
configuration conforme au RFC que j'utilise :
P100D
1
0
