Résumé

  • Sur un rejeu de requêtes .nl, des chercheurs de l’Université de Twente et de SIDN Labs ont mesuré 655 octets pour la signature Falcon-512 compressée médiane, contre 666 pour le format rembourré fixe. Les onze octets gagnés ont très peu changé le passage des réponses DNSSEC sous les seuils étudiés.
  • Le nombre de preuves signées dans une réponse, surtout quand un nom n’existe pas, pèse bien plus lourd que l’économie obtenue sur une signature isolée.

Le petit régime de la grosse enveloppe

Une enveloppe dépasse le tarif postal. On retire onze grammes de papier. Le bureau annonce une victoire d’efficacité, puis remet l’enveloppe sur la balance : elle dépasse toujours le tarif. Dans le DNS, la balance ne pèse d’ailleurs pas une signature seule. Elle pèse la réponse entière, avec parfois plusieurs preuves cryptographiques. C’est là que la belle ligne du tableau comparatif rencontre le guichet.

Les auteurs d’une étude publiée en 2025 par l’Université de Twente et SIDN Labs ont fait passer Falcon-512 à ce guichet. L’algorithme peut produire une signature compressée de longueur variable ou une signature rembourrée de longueur fixe. Dans leur zone d’essai .nl, la médiane des signatures compressées atteint 655 octets; la version rembourrée occupe toujours 666 octets. L’écart est réel. Son rendement dans les messages DNSSEC l’est beaucoup moins.

Le protocole expérimental mérite d’être lu avant le résultat. Les chercheurs ont pris la zone .nl du 3 avril 2025, retiré ses données DNSSEC existantes, signé deux copies avec les deux formats de Falcon-512, puis rejoué une journée de requêtes observées vers deux serveurs NSD d’essai. Ils ont retenu 59 312 128 réponses restées NOERROR lors du rejeu et 113 348 878 restées NXDOMAIN. Le trafic de départ était réel; les réponses Falcon provenaient de la simulation. Aucun de ces nombres ne décrit un déploiement Falcon en production par le registre .nl.

Les réponses NOERROR racontent une histoire presque décevante pour les amateurs de compression. La majorité passait déjà sous les seuils de 1 232 et 1 500 octets choisis par les auteurs. Une minorité appréciable dépassait ces limites, notamment lorsqu’une preuve NSEC3 signée supplémentaire devait établir l’absence de DS pour un domaine enfant non signé. Dans les deux cas, le format compressé déplaçait peu de réponses d’un côté à l’autre de la limite. L’économie sur une signature ne payait pas la présence d’une preuve de plus.

Les réponses NXDOMAIN, celles qui disent qu’un nom demandé n’existe pas, ont supprimé tout suspense. Toutes les réponses retenues dans ce groupe dépassaient les deux seuils. Avec deux enregistrements NSEC3 signés, elles mesuraient entre 2 269 et 2 420 octets. Avec trois, entre 3 075 et 3 767 octets. Une signature légèrement plus courte ne transforme pas un message de plus de trois kilooctets en réponse de 1 232 octets. Le nombre de pièces jointes a gagné le procès avant même l’examen de leur épaisseur.

Le format compressé n’est pas non plus une taille garantie. Parmi 9 912 711 signatures de la zone d’essai, les chercheurs en ont observé une de 667 octets. Le format rembourré reste à 666 octets parce que le signataire recommence lorsqu’une signature dépasse cette longueur. Un cas sur presque dix millions ne suffit pas à condamner un format. Il rappelle simplement que le logiciel doit gérer une distribution, y compris ses bords, tandis qu’une taille fixe simplifie certaines décisions d’implémentation.

La conclusion du papier propose donc d’examiner sérieusement le format rembourré pour sa prévisibilité et pour réduire les risques d’erreurs de mise en œuvre. Les auteurs ont étudié les tailles des messages, pas établi le coût complet du calcul, de la mémoire, du matériel cryptographique ou du déploiement. Leur constat demeure précis : dans ce rejeu, la compression n’a pas fait entrer une part sensiblement plus grande des réponses sous les limites retenues. C’est une objection opérationnelle à un argument de vente, pas une décision de normalisation déjà prise.

Le calendrier confirme que la décision reste ouverte. La page officielle du NIST, mise à jour le 27 octobre 2026, place encore FIPS 206, dérivé de Falcon, en développement. Un Internet-Draft individuel publié par Paul Hoffman, de l’ICANN, énumère les questions à confronter pour DNSSEC : taille des enregistrements, vitesse de déploiement, charge CPU, changements du protocole, modules de sécurité matériels, cryptanalyse et licences de brevet. Ce document de travail n’a pas le statut d’une norme IETF. Sa liste a néanmoins une qualité rare : elle ne laisse pas un seul chiffre faire semblant d’être le dossier entier.

Le programme de RIPE 93 annonce une présentation de Ginevra Fabrizio sur ce travail le 29 octobre. Au 28 octobre, c’est le papier publié qui permet d’évaluer les résultats; la conférence n’a pas encore rendu de verdict. Une discussion utile devrait demander les distributions de réponses complètes, les types de requêtes, le nombre de signatures par message et la fréquence de retour à TCP. Les onze octets doivent faire la preuve de leur utilité au guichet, pas dans la brochure.

Qui vote : la moyenne ou le paquet ?

La normalisation aime les propriétés faciles à ranger en colonnes. La médiane d’une signature s’y prête admirablement. Une réponse DNS, elle, arrive avec la longueur d’un nom, un type de requête, l’état d’une délégation et, parfois, plusieurs preuves d’inexistence. L’étude observe que la variation de longueur des noms est du même ordre que celle des signatures compressées. Le réel ajoute ses propres octets sans demander l’avis du tableau.

La primauté du code qui fonctionne impose ici un examen très concret : publier les réponses qui traversent réellement les seuils. Une économie de composant peut être précieuse pour le stockage ou d’autres usages. Pour la livraison DNSSEC mesurée dans cette zone, elle n’a presque pas changé la catégorie des paquets. Appeler cela un succès de transport reviendrait à annoncer une baisse du prix d’un timbre alors que la lettre exige toujours un colis.