Mon blog

La plaie de DNSSEC, comme celle de tous les systèmes de cryptographie, est la gestion des clés. Avec DNSSEC, la clé de signature des autres clés, la KSK (Key Signing Key) est censée être remplacée (rolled over) régulièrement. Si un résolveur a une KSK dans sa configuration, cela oblige l'administrateur du résolveur à effectuer le remplacement à la main, ce qui peut être contraignant. Notre RFC 5011 propose une autre solution : le domaine signe la nouvelle KSK avec l'ancienne et le résolveur accepte alors automatiquement cette nouvelle clé.

Le résolveur peut ainsi construire une chaîne de confiance menant de la première clé pour laquelle il a été configuré, jusqu'à la clé actuelle. Cela implique que ledit résolveur aie un espace où écrire les clés successives qu'il a authentifié et décidé de garder.

Bien sûr, s'il n'y avait qu'une seule KSK (Key Signing Key, cf. RFC 3757), celle de la racine du DNS, tout serait plus simple, on pourrait envisager de gérer cette unique clé à la main. Mais, aujourd'hui, la racine n'est pas signée et, même si elle l'était, il subsistera pendant longtemps (voir section 1) des domaines de tête non signés (.com ne sera pas signé avec 2011, voire 2012). En outre, on peut souhaiter ne pas dépendre de la clé de la racine, pour des raisons politiques. La méthode de notre RFC présente des risques (cf. section 8.3) mais pas plus que la situation actuelle où les clés sont entièrement gérées à la main.

Ce RFC 5011 fournit donc un moyen de ne configurer la clé d'un domaine qu'une seule fois (cette configuration initiale reste manuelle), même si elle est remplacée par la suite. Le principe est simple (et le RFC est donc très court). La section 2 le décrit : quand une clé est configurée pour une zone du DNS (cette clé est dite un « trust anchor ») et qu'une nouvelle KSK apparait dans la zone, signée par l'ancienne, le résolveur accepte cette nouvelle KSK comme trust anchor et l'enregistre dans sa configuration. Une machine à états complète figure en section 4.

Le principal piège avec cette méthode est que, si une clé privée est volée, l'attaquant pourra continuer à générer une chaîne de confiance : le retrait de la clé compromise par le gérant de la zone ne suffira pas à annuler son usage. Il faut donc un mécanisme de révocation (section 2.1). Lorsqu'une KSK est publiée, signée mais que le nouveau bit REVOKE est mis, alors le résolveur doit retirer cette clé de sa configuration.

Un autre risque est que la clé privée soit volée sans que le gérant de la zone ne s'en rende compte immédiatement. Pour éviter que l'attaquant ne fasse accepter une nouvelle clé, le résolveur est supposé attendre lorsqu'une clé apparait (section 2.2). La durée d'attente est typiquement de 30 jours (section 2.4.1).

Le résolveur qui met en œuvre ce RFC 5011 doit périodiquement vérifier que la clé est toujours en service. La section 2.3 expose les règles à suivre pour cette vérification (il faut demander souvent pour détecter les nouvelles clés, sans attendre l'expiration du TTL mais pas trop pour ne pas surcharger les serveurs).

On l'a vu, ce RFC crée un nouveau booléen dans les enregistrement DNSKEY, pour indiquer la révocation. Le format est donc légèrement modifié, comme spécifié en section 3. C'est le bit n° 8 du champ DNSKEY Flags (voir section 2.1.1 du RFC 4034) qui servira à cet effet.

Si toutes les clés d'une zone sont révoquées, la zone devient non-validable (section 5), ce qui signifie qu'elle sera traitée comme si elle n'était pas signée du tout (insecure en terminologie DNSSEC).

Le bon fonctionnement de l'algorithme nécessite que la zone signée procède au remplacement des clés d'une manière particulière, décrite en section 6. Ainsi, le remplacement (rollover) va nécessiter la révocation de l'ancienne clé.

La prochaine version de BIND, la 9.7, actuellement en béta-test privée, introduira le système de ce RFC. (Voir le fichier README.rfc5011 dans le code source.) Cela se configurera avec la directive managed-keys, qui ressemble beaucoup à trusted-keys, par exemple ainsi :

managed-keys {
    "example.com."     initial-key             257 3 5 
                                "AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ
                                1wcTkypSExLCBPMS0wWkrA1n7t5hcM86VD94L8oEd9jn
                                HdjxreguOZYEBWkckajU0tBWwEPMoEwepknpB14la1wy
                                3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6FdFL9wyC
                                flV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3Aa
                                pH2GXCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNS
                                M4q3zGhuly4NrF/t9s9jakbWzd4PM1Q551XIEphRGyqc
                                bA2JTU3/mcUVKfgrH7nxaPz5DoUB7TKYyQgsTlc=";
                                // key id = 8779
};

Une fois que BIND démarre, il crée un journal pour une zone bidon, managed-keys.bind et commence le processus décrit dans le RFC :

23-Oct-2009 10:55:10.152 zone managed-keys.bind/IN/_meta: loaded serial 0
23-Oct-2009 10:55:10.169 zone managed-keys.bind/IN/_meta: Initializing automatic trust anchor management for zone 'example.com'; \
   DNSKEY ID 49678 is now trusted, waiving the normal 30-day waiting period.

On voit que example.com a déjà une nouvelle clé, 49678, signée avec l'ancienne (celle que j'ai configurée dans manage-keys) et que BIND commence la période d'attente.