RFC 3090 : une zone, deux réponses de sécurité

Résumé

RFC 3090 a remplacé les états par algorithme et l’étiquette « expérimentalement sûre » par trois attributs : globalement sécurisée, localement sécurisée et non sécurisée.
Le résolveur gardait pourtant une décision binaire, construite avec ses propres ancres, ses algorithmes, le parent observé et le chemin de validation choisi.

Quatre acteurs ne posaient pas exactement la même question

Au début de 2001, le déploiement DNSSEC avançait par fragments. Une zone pouvait signer ses données sans que son parent soit prêt à relier cette signature à la racine du DNS. Certains résolveurs recevaient directement la clé d’une zone de test ; d’autres n’en savaient rien. Le vocabulaire de RFC 2535 risquait alors de donner à « sécurisé » une portée que les faits ne justifiaient pas.

RFC 3090 distingue l’administrateur de la zone, le serveur de mise à jour dynamique, le parent délégant et le résolveur. Le premier décide quelles données signer. Le serveur doit préserver cet état lors d’une modification. Le parent fournit une partie de la transition de confiance. Le résolveur, enfin, décide si le chemin qu’il peut réellement construire autorise la validation. Aucun de ces gestes ne remplace les trois autres.

Le texte abandonne donc un statut différent pour chaque algorithme : la zone reçoit un seul attribut administratif. Il retire aussi « expérimentalement sûre ». Pour les machines configurées avec la clé d’essai, l’expérience est un îlot localement sécurisé ; pour l’Internet général, elle reste non sécurisée. L’expérience change le groupe d’observateurs, pas la nature du raisonnement.

Un îlot n’existait que pour ceux qui en possédaient la carte

Un ensemble contigu de zones signées pouvait exister sous un parent non sécurisé. Le sommet de cet ensemble formait une racine locale. En installant sa clé comme ancre de confiance, un exploitant de résolveurs pouvait valider les descendants sans disposer d’une chaîne partant de la racine mondiale.

La même zone produisait ainsi deux descriptions exactes. Elle était localement sécurisée pour les résolveurs qui connaissaient l’ancre et acceptaient le chemin. Elle était non sécurisée pour ceux qui ne disposaient pas de ce point de départ. La zone autoritative n’avait pas changé ; l’état local du vérificateur, lui, avait changé.

Encore fallait-il choisir la bonne racine. RFC 3090 appelle racine de sécurité la plus proche celle dont le nom possède la plus longue correspondance ordonnée sur les étiquettes situées à droite du nom recherché. Partir d’une ancre plus éloignée pouvait conduire à une clé NULL sur le chemin et à une conclusion d’insécurité, alors qu’un îlot plus proche était configuré. Des îlots imbriqués ou superposés n’étaient donc pas une curiosité théorique : ils pouvaient révéler un défaut de configuration ou de sélection.

Une signature capturée ne raconte pas cette histoire entière. Il faut conserver l’ensemble des ancres du résolveur, l’algorithme de choix du point de départ, les algorithmes acceptés, les données récupérées, l’heure et la politique locale. « Validé » est le résultat d’un assemblage daté, pas une peinture permanente appliquée à la zone.

Le parent pouvait affirmer la sécurité par une absence

La frontière entre parent et enfant portait une convention déroutante de la génération RFC 2535. Pour un parent lui-même sécurisé, l’absence de KEY enfant pouvait signifier que l’enfant était sécurisé, tandis qu’une clé NULL signée signalait un enfant non sécurisé. Le cas positif pouvait donc apparaître comme un silence, et le cas négatif comme un objet signé.

RFC 3090 juge cette forme contre-intuitive et inconfortable pour l’exploitation. Elle ne la remplace pas ; elle fixe la façon dont les logiciels devaient l’interpréter. Cela interdit de transformer toute absence de record en preuve. L’absence n’avait ce sens qu’à un point authentifié, dans cette génération du protocole, avec le reste du chemin établi.

RFC 3658 introduira ensuite DS. Les RFC 4033, 4034 et 4035 installeront l’architecture moderne DNSKEY, RRSIG, NSEC et DS à la place de KEY, SIG et NXT. Ces textes expliquent l’évolution, mais ils ne doivent pas servir à réécrire rétrospectivement ce que les opérateurs de 2001 publiaient et vérifiaient.

Global n’était pas synonyme de garantie absolue

La zone globalement sécurisée de RFC 3090 devait utiliser les algorithmes obligatoires, appartenir à une chaîne de signatures parentales située dans l’arbre, publier les clés de signature appropriées au sommet, couvrir l’espace avec NXT et signer les ensembles concernés. Une zone localement sécurisée pouvait emprunter un chemin préconfiguré hors arbre ou d’autres algorithmes, tout en respectant les propriétés d’une zone signée. Le reste était non sécurisé.

Le document précise pourtant que « global » et « local » décrivent des attributs ; ils ne certifient pas la conformité. Un résolveur restrictif ne reconnaîtrait que la première classe. Un résolveur doté de capacités ou d’une configuration supplémentaires pourrait accepter une partie de la seconde. À l’usage, chacun ramenait le monde à deux résultats : sécurisé ou non sécurisé.

Même le meilleur attribut ne supprimait pas les défaillances. Un résolveur pouvait mal se comporter, un parent pouvait être compromis, une implémentation pouvait ne pas suivre la norme. L’apport de RFC 3090 fut de rendre les responsabilités observables : contenu de l’enfant, déclaration du parent, configuration du résolveur et règle de composition. Il ne transforma pas l’un de ces contrôles en pouvoir universel.

La même zone était sûre ici et non sécurisée ailleurs : RFC 3090

Pourquoi c'est important

Résumé

Quatre acteurs ne posaient pas exactement la même question

Un îlot n’existait que pour ceux qui en possédaient la carte

Le parent pouvait affirmer la sécurité par une absence

Global n’était pas synonyme de garantie absolue

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance