Résumé

  • La RFC 3008 ne considérait une signature de données comme pertinente pour DNSSEC qu'après contrôle de ses champs et de l'autorité d'une clé de zone correspondante ; réussir le calcul n'était qu'une étape.
  • Les clés d'hôte et d'utilisateur pouvaient encore authentifier une transaction SIG(0), tandis que la clé de zone attestait les données publiées, séparant demande de changement et parole publique de la zone.

La cryptographie pouvait répondre « oui » à la mauvaise question. Une signature pouvait correspondre exactement à une clé et au contenu couvert sans que cette clé ait le droit de représenter la zone. C'est cette erreur de catégorie que la RFC 3008, publiée en novembre 2000, a voulu rendre impossible dans le comportement normal d'un résolveur DNSSEC.

Le texte parlait de signatures « matérielles » et « immatérielles ». Une signature de données couvre un RRset et peut participer à la validation DNSSEC. Une autre signature peut avoir une fonction propre à une application, ne couvrir aucun RRset, ou protéger un message DNS sous la forme SIG(0). Elle n'est pas nécessairement fausse. Elle est simplement hors de la chaîne de preuve que le résolveur construit pour les données publiques de la zone.

Cette taxonomie resserrait le modèle de la RFC 2535. Celui-ci avait ménagé une place aux clés de zone, d'hôte et d'utilisateur comme signataires de données. L'idée répondait notamment au problème de la mise à jour dynamique : laisser l'hôte signer ce qu'il apporte pouvait éviter d'exposer en ligne la clé privée centrale de la zone.

La promesse ne tenait pourtant pas sur tout le parcours. Dans une zone sécurisée acceptant des changements, les ensembles SOA et NXT devaient eux aussi être resignés. Le mécanisme de mise à jour sécurisée de la RFC 3007 exigeait donc déjà une capacité de signature de zone en ligne. Dès lors que cette clé devait exister et pouvait signer les données reçues, donner aux signatures d'utilisateur ou d'hôte une autorité DNSSEC publique ne supprimait plus l'exposition recherchée. Cela ajoutait surtout une décision compliquée chez chaque résolveur.

La RFC 3008 a choisi une règle plus étroite : dans une zone sécurisée, les données sont signées par une clé de zone. Un résolveur ignore normalement les autres types de clé lorsqu'il évalue une signature de données, sauf politique locale explicite. Ce choix sacrifiait une partie de la flexibilité du schéma précédent. En échange, la longueur de la chaîne de vérification devenait bornée par la profondeur des labels et l'autorité suivait l'organisation visible des zones.

Le mot « zone » ne constituait pas un passe-droit. Avant même la vérification mathématique, plusieurs conditions filtraient une signature. Le type couvert devait correspondre au RRset. L'algorithme devait être connu et disposer d'un format SIG défini. Le nombre de labels ne pouvait dépasser celui du nom propriétaire. Le TTL original devait être au moins égal au TTL actuel de la signature, puisqu'un serveur intermédiaire ne peut l'augmenter. L'instant de validation devait tomber entre l'entrée en vigueur et l'expiration.

Le nom du signataire, le key tag et l'algorithme devaient ensuite désigner une KEY candidate. Sans clé correspondante, la signature devenait immatérielle. Si plusieurs clés partageaient ces sélecteurs, elles restaient toutes candidates jusqu'à ce que la vérification indique laquelle avait produit la valeur. Une opération réussie n'autorisait donc pas le résolveur à inventer rétroactivement le rôle de la clé.

La KEY apportait ses propres conditions. Ses bits de type devaient permettre l'authentification. Pour une signature de données matérielle, son type de nom devait être zone. Son octet de protocole devait annoncer DNSSEC ou ALL. Son algorithme devait être identique à celui de la SIG. Une paire de clés capable de signer pouvait ainsi être écartée parce qu'elle avait été déclarée pour un autre usage.

Cette séquence produit plusieurs reçus indépendants. La vérification cryptographique relie une clé, une signature et des octets. L'éligibilité indique que les champs ont une forme admissible. L'autorité de signataire rattache la clé à la zone. La chaîne de confiance relie cette zone à un point déjà accepté. Même leur réunion ne prouve pas que l'adresse publiée répond, que l'organisation décrite existe encore ou que la donnée est judicieuse. DNSSEC protège une assertion DNS ; il ne certifie pas toute la réalité désignée.

Une autre voie demeurait ouverte aux hôtes et aux utilisateurs. Une SIG dont le type couvert vaut zéro protège le message DNS entier : c'est SIG(0), détaillée dans la RFC 2931. Le signataire attendu est alors un utilisateur ou un hôte, parce qu'une transaction est lancée par un acteur et non par une zone. Même un serveur de noms agit ici comme hôte. Une clé de zone ne devait normalement pas produire cette signature de transaction.

La séparation était fonctionnelle, non hiérarchique. Une clé d'hôte pouvait prouver l'origine d'une demande de mise à jour sans pour autant créer des RRsets dont tous les résolveurs devraient accepter directement la signature. Le serveur primaire authentifiait le principal, puis appliquait la politique locale de la RFC 3007 : noms, types de RR et actions permises, avec refus par défaut. Après admission, la clé de zone attestait l'état destiné au public.

Proposer, autoriser et publier restaient ainsi trois pouvoirs. Le résolveur n'avait pas à connaître la liste privée des droits accordés par le primaire à chaque client. Il voyait une règle commune pour les données de zone. Le primaire pouvait faire évoluer son contrôle d'accès sans encoder chaque politique future dans le protocole public.

Le vieux champ signatory de KEY illustrait ce renoncement. La RFC 3008 ne lui attribuait aucune valeur et n'en exigeait aucune. Quelques bits semblaient pouvoir transporter toute l'autorité, mais ils auraient figé ensemble politique de mise à jour et validation publique. Le texte préférait deux surfaces explicites : politique locale au point d'admission, rôle de clé de zone au point de validation.

Il faut maintenir la frontière historique. La RFC 3090 a précisé le statut sécurisé d'une zone dans l'ancien cadre. La RFC 3658 a ensuite introduit DS et modifié le raccordement entre parent et enfant. Les RFC 4033, 4034 et 4035 ont finalement rendu obsolètes les mécanismes KEY et SIG de cette génération.

La RFC 3008 n'est donc pas un manuel de configuration actuel. Ses drapeaux KEY ne doivent pas être projetés sans explication sur DNSKEY et RRSIG. La RFC 3130 rapporte d'ailleurs qu'en 2001 DNSSEC était perçu comme une boîte à outils dont les pièces avançaient à des vitesses différentes. Ce constat documente une phase de conception ; il ne mesure ni déploiement universel ni gain de sécurité attribuable à cette seule règle.

L'apport durable est plus abstrait. Une preuve correctement formée n'apporte pas son propre mandat. Le code qui la reçoit doit connaître le rôle du signataire, la portée de l'objet, la fenêtre temporelle, le protocole annoncé et le chemin de confiance. Sinon, la précision mathématique risque de donner à une clé plus de pouvoir que l'architecture ne lui en avait confié.

Dans la lecture Running-Code Primacy de Lu Heng, l'autorité naît quand le résolveur exécute cette chaîne complète, non quand un objet signé est simplement présent. La spécification minimale commune est le recours à la clé de zone. Une politique locale peut l'augmenter, mais l'exception reste chez celui qui la prend et ne devient pas silencieusement la règle de tous. La stabilité dépend de la conservation de chaque reçu plutôt que d'un voyant unique « signature valide ».

La RFC 3008 a donc retiré à la signature son aura de décision totale. La clé prouve une possession, ses champs annoncent un usage, sa place dans la zone fournit un rôle, la chaîne fournit une confiance et l'horloge délimite la validité. L'autorité n'existe que lorsque ces éléments convergent pour cette donnée précise.

Sources