La
Normalisé dans le
Il n'est pas évident de savoir si SHA-1 est vraiment vulnérable dès aujourd'hui. Plusieurs attaques ont été publiées dans la littérature ouverte (et il y en a donc sans doute bien d'autres, gardées secrètes) mais elles ne semblent pas facilement exploitables, surtout dans le cas de l'utilisation particulière qu'en fait DNSSEC. Néanmoins, le remplacement de SHA-1 était une nécessité, compte-tenu du fait que les attaques ne peuvent que s'améliorer (voir la section 8 pour un exposé plus détaillé), et parce qu'un tel remplacement prend du temps (par exemple, l'élaboration de ce RFC a été très longue).
Le remplaçant, SHA-2, décrit dans la norme
SHA-2 est utilisable dans les enregistrements de type
La section 2 décrit les enregistrements DNSKEY. Comme la clé
publique ne dépend pas de l'algorithme de hachage utilisé
ultérieurement, on pourrait penser qu'ils ne sont pas modifiés. Mais
il est important d'indiquer au résolveur cet algorithme de hachage car
tous les résolveurs ne connaissent pas SHA-2 du jour au lendemain. Il
faut donc qu'ils sachent tout de suite, en examinant la clé, s'ils
pourront valider la zone ou pas. (Sinon, ils considéreront la zone
comme étant non signée.) Les
Les signatures (enregistrements
Les signatures faites avec RSA + SHA-256 seront stockées avec le numéro d'algorithme 8 et leur codage aura un préfixe spécifique, pour les distinguer des signatures faites avec d'autres fonctions (section 3.1). Idem pour celles faites avec RSA + SHA-512 (section 3.2).
Et les problèmes pratiques du déploiement ? Pas de panique, ils
sont dans la section 4. La taille des clés elle-mêmes n'est pas
couverte (section 4.1) mais déferrée aux recommendations du
Quels logiciels peuvent aujourd'hui utiliser ces algorithmes ? Pour
Voici un exemple d'utilisation du programme
% ldns-keygen -a RSASHA256 vachement-secure.example
Kvachement-secure.example.+008+23094
% cat Kvachement-secure.example.+008+23094.key
vachement-secure.example. 3600 IN DNSKEY 256 3 8 \
AwEAAc87fkhQ3RehZ9AWUtataphm6Ku+DLKgtUPp/Zi0mwhtDN36oWBhzUt5a82Zeat4zsbC6WjIDWWqOx33cWh3ISMKDK0cOu1kMRCZTXS98WoSA0TgfMBdGdaK/Z+yLX+COq8HL72gBDG/RuDqIOwdtCBhbDluIwafzPAw3l2rIEiR \
;{id = 23094 (zsk), size = 1024b}
Et lorsqu'on la signe :
% ldns-signzone vachement-secure.example.zone Kvachement-secure.example.+008+23094
% cat vachement-secure.example.zone.signed
...
. 3600 IN SOA localhost. root.localhost. 1 604800 86400 2419200 604800
. 3600 IN RRSIG SOA 8 0 3600 \
20091125150944 20091028150944 23094 . nvIldICQaBpHR/Fn264gL
7bl5RCzzM6h3S5o6k/yq9cFRhYpOO4FQGfozP2q8A7whoHfymCg1D6harOt7b0ffO+TA1iBddpF1DJLQ/DKPhfS2REqXbXjpveU3uQNK
g0jOdj7G6hrSQl9wXg3Co5yL84jG33oSlDWQM9QhKUyAUk= \
;{id = 23094}
Comme il y a déjà eu des attaques de
Enfin, la section 8.2 explique pourquoi SHA-2 n'est pas vulnérable
aux attaques par repli : si une zone a deux clés, utilisant SHA-1 et
SHA-2, un méchant ne peut pas forcer l'utilisation de l'algorithme le
plus faible car les enregistrements DNSSEC doivent être signés avec
Si on veut voir des signatures en vrai, la racine, et des TLD comme