Résumé

  • RFC 3445 réserva les nouveaux enregistrements KEY au protocole 3, DNSSEC : une requête ne pouvait choisir le sous-type interne et une signature portait sur le RRset complet.
  • La migration fut asymétrique : ne plus publier les anciennes valeurs, mais les conserver à la lecture pendant la validation, faute de quoi le retrait d’un membre invalidait la signature et divisait les caches.

Le tiroir commun n’avait pas de compartiments

RFC 2535 avait défini KEY avec des drapeaux, un octet de protocole, un algorithme et une clé publique. La valeur 1 visait le courrier, 2 IPsec, 3 DNSSEC, 4 TLS; 5 à 254 restaient disponibles et 255 signifiait tout protocole. Sur le papier, le DNS devenait un meuble universel pour clés publiques.

Or la requête DNS connaissait le type KEY, pas la valeur de protocole contenue dans ses données. Pour obtenir une clé, le client recevait toutes les clés du même nom. Et DNSSEC signait l’ensemble, non une sélection adaptée à l’application. Le format avait plusieurs usages mais une seule unité de recherche et de preuve.

RFC 3445, publié en décembre 2002, transforma les difficultés d’un déploiement expérimental limité en frontière normative. Son texte, sa notice, le Datatracker, l’historique, les références, les citations ultérieures et les errata prouvent le parcours documentaire, pas l’étendue du déploiement.

Même encodage, autorités différentes

Le RFC énumérait six écarts : finalité, administrateur, règle d’authentification, inclusion par le serveur faisant autorité, traitement par le résolveur, conséquence d’une panne ou d’une compromission. Une clé DNSSEC fait partie de l’infrastructure nécessaire à l’intégrité du DNS. Une clé applicative n’a, pour le DNS lui-même, aucune sémantique particulière.

Le RRset mêlé pouvait grossir, alourdir chaque réponse et synchroniser des rotations sans rapport. Plus grave, un résolveur négligent pouvait prendre une clé applicative compromise pour une clé de zone s’il ignorait l’octet de protocole. Une signature valide ne corrige pas la mauvaise question posée à la mauvaise autorité.

RFC 3445 imposa donc la valeur 3 aux nouvelles données faisant autorité. Tous les bits de drapeau, sauf le bit de zone 7, furent réservés. Les anciennes valeurs applicatives et 255 devinrent réservées; de nouvelles attributions exigeaient une Standards Action. Les usages DNSSEC liés à RFC 2930, RFC 2931 et RFC 3007 restaient possibles, mais l’ancienne distinction hôte/utilisateur disparaissait.

Interdire l’usage sans mutiler la preuve

Le lecteur ne devait pourtant pas éliminer mécaniquement les valeurs différentes de 3. Il lui était interdit de les employer pour authentifier le DNS, mais il devait les garder dans l’ensemble soumis à vérification. Le signataire avait couvert le RRset complet. Filtrer un élément avant calcul revenait à vérifier un autre objet et faisait échouer SIG; filtrer différemment selon les caches créait aussi des vues incohérentes.

Ne pas accorder d’autorité à une clé et conserver ses octets comme partie de la preuve sont deux opérations distinctes. La règle de migration devient : fermer la production, maintenir la compréhension nécessaire, retirer le pouvoir sémantique, puis attendre la convergence prouvée.

Les RFC 4033, 4034 et 4035 remplacèrent ensuite la famille 2535 et nommèrent DNSKEY la clé de l’infrastructure. D’autres conteneurs spécialisés apparurent : SSHFP, CERT, TLSA. Ils illustrent une séparation ultérieure sans prouver une causalité unique. Le registre IANA atteste les valeurs; il n’atteste ni l’adoption, ni le code, ni la sûreté.

La frontière la plus petite qui partage réellement la confiance

La discipline des couches de réalité de Heng Lu sépare l’attribution d’un nombre, la validité cryptographique, l’autorité administrative, le déploiement et le résultat. Les réunir dans KEY ne les fusionnait pas. La primauté du code en fonctionnement explique pourquoi l’expérience comptait : elle révéla que le modèle propre transférait des coûts réels aux requêtes, signatures et caches. La spécification initiale minimale suggère de normaliser le noyau dont les participants partagent réellement les règles, sans faire du DNS l’autorité universelle de toute clé.

Cette lecture n’attribue pas d’intention personnelle aux auteurs. Elle retient une leçon vérifiable : même forme binaire ne signifie pas même domaine de confiance. Lorsque recherche, signature et cache déplacent plusieurs objets comme un tout, la limite du set devient une limite de sécurité et de gouvernance.

Sources