Résumé

  • La capture du 12 septembre recense 150 fichiers de données DNS inverses, regroupés en 75 paires de noms, ainsi que 150 signatures détachées et une clé publique placée dans le même répertoire.
  • La paire examinée contenait exactement les mêmes 2 222 octets et la somme MD5 publiée correspondait. Ces contrôles portent sur un fichier; ils ne définissent pas le contenu attendu du lot entier.
  • L’absence de manifeste ne révèle ni fichier manquant ni panne DNS. Elle laisse seulement sans preuve signée l’achèvement d’une publication complète.

Un fichier peut être parfaitement authentique et appartenir à un ensemble incomplet. C’est ce détail, peu spectaculaire mais opérationnel, que fait apparaître le répertoire de LACNIC.

Au moment de la capture, 75 noms suivaient le modèle à trois chiffres — 002-LACNIC, par exemple — et 75 autres reprenaient le même nombre sous la forme 2.in-addr.arpa-LACNIC. Chaque nom court avait son correspondant. Chacun des 150 noms de données était accompagné d’une entrée .asc; le répertoire proposait aussi PUBLIC_KEY. On y trouvait 151 entrées .md5, soit une par nom de données et l’entrée générique vide *-LACNIC.md5 affichée par l’index.

Cette organisation rend la vérification unitaire possible. Le consommateur connaît le fichier, trouve la signature qui porte le même nom et dispose d’une clé publique voisine. Pour l’exemple contrôlé, les deux variantes de nom produisaient le même condensat SHA-256 et la valeur MD5 annoncée concordait avec les octets reçus.

Le saut injustifié consisterait à appeler cela une preuve de lot.

Quatre questions que le répertoire ne confond pas toujours

L’intégrité demande si les octets ont changé. La provenance demande quelle clé a signé le fichier et si le vérificateur accepte cette clé pour cet usage. L’exhaustivité demande si tous les objets attendus sont présents. L’atomicité demande enfin si ces objets décrivent le même état de publication.

Les signatures détachées d’OpenPGP, définies par le RFC 9580, portent sur des données externes. Elles peuvent donc répondre à la première et à une partie de la deuxième question, à condition de procéder réellement à la vérification. Elles ne contiennent pas, par magie, la liste des 149 autres noms attendus.

La présente enquête n’a pas validé les signatures: aucun vérificateur OpenPGP n’était disponible dans l’environnement local. Elle ne conclut donc ni à leur validité ni à un problème de clé. Elle constate simplement que le matériel de contrôle unitaire est public.

La somme MD5 joue un rôle encore plus étroit. Elle a concordé pour l’échantillon, ce qui est utile contre une erreur de transfert. Le RFC 6151 écarte MD5 lorsque la résistance aux collisions est requise, tout en laissant subsister certains usages limités à la détection d’erreurs. Une somme correcte n’authentifie ni l’auteur ni la composition du lot.

Pourquoi le choix actuel reste défendable

LACNIC n’a peut-être jamais promis un instantané transactionnel. Le répertoire peut servir à récupérer un fragment connu, par son nom, indépendamment des autres. Dans ce modèle, la granularité fine est une qualité: un fichier peut être mis en cache ou renouvelé sans imposer le transfert de tout l’ensemble.

Les deux variantes de nom peuvent aussi répondre à des besoins de compatibilité. Leur horodatage HTTP différait d’une seconde dans l’échantillon, sans que cela démontre un décalage substantiel. La copie reçue contenait des lignes de délégation NS; elle ne constituait ni une interrogation du DNS en production ni une capture de toute la zone faisant autorité.

La critique commence uniquement lorsqu’un miroir veut reproduire le répertoire. L’index HTML montre ce que le serveur a affiché à un instant, mais aucun nom de fichier n’y signalait un README, un manifeste, un index SHA-256 ou une version de publication. Le miroir ne peut donc pas distinguer, à l’aide d’un objet signé, un lot terminé d’une vue prise pendant son renouvellement.

Un manifeste très léger suffirait

LACNIC pourrait conserver tous les fichiers actuels et ajouter un seul document signé. Celui-ci donnerait l’identifiant du lot, l’heure de génération et l’heure d’achèvement, puis la liste ordonnée des noms attendus. Chaque ligne préciserait l’identifiant de la paire, le rôle du nom, la taille, le SHA-256 et le nom de la signature.

Le reçu devrait aussi publier l’empreinte de la clé admise, le lot précédent et l’état «publication achevée». Une correction créerait une nouvelle version reliée à celle qu’elle remplace. Les anciens manifestes resteraient consultables.

Ce dispositif ne présumerait pas que les 75 paires restent toujours identiques. Au contraire, il donnerait à LACNIC l’endroit où documenter une différence volontaire. Il ne certifierait pas non plus que le fichier téléchargé est chargé sur tous les serveurs faisant autorité. Le manifeste prouverait une décision de publication, rien de plus.

Les 150 signatures répondent déjà à une question utile: peut-on rattacher chaque fichier à un contrôle cryptographique? Le manifeste ajouterait la question manquante: quel ensemble ces fichiers devaient-ils former à cette date? Pour une consommation unitaire, la différence est secondaire. Pour un miroir, elle définit le produit.

Sources