Double-Signed Fragmented DNSSEC for Countering Quantum Threat

Informations Fondamentales

• ID de l'article: 2411.07535
• Titre: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• Auteurs: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• Institutions: Deakin Cyber Research and Innovation Centre (Australie), Cyber Security Cooperative Research Centre (Australie), Quintessence Labs (Canberra), Tata Consultancy Services (Brisbane)
• Classification: cs.CR (Cryptographie et Sécurité)
• Conférence de publication: C'25, novembre 2025 (version préliminaire acceptée à ITNAC 2025)
• Lien de l'article: https://arxiv.org/abs/2411.07535

Résumé

DNSSEC, en tant qu'extension de sécurité du DNS, est crucial pour la conversion précise des noms de domaine en adresses IP. Les signatures numériques fournissent la base de cette conversion fiable, cependant le développement des ordinateurs quantiques rend les signatures numériques traditionnelles vulnérables. Le NIST a récemment sélectionné des signatures numériques post-quantiques qui fonctionnent sur des ordinateurs classiques et résistent aux attaques des ordinateurs quantiques. Étant donné que ces signatures post-quantiques en sont encore aux premiers stades de développement, il existe un risque à remplacer les signatures pré-quantiques dans DNSSEC par des candidats post-quantiques avant une analyse de sécurité approfondie. Cette recherche explore la faisabilité d'adopter une « double signature » dans DNSSEC, combinant les signatures post-quantiques et classiques. La double signature fournira simultanément une protection contre les menaces quantiques et les attaques non-quantiques inconnues. Cependant, l'inclusion de deux signatures entre en conflit avec la taille maximale autorisée des réponses DNSSEC (1232B, limitée par le MTU de la liaison physique). Pour résoudre ce problème, cet article adopte une méthode de fragmentation au niveau applicatif pour traiter les réponses DNSSEC avec double signature. La solution implémentée sur OQS-BIND montre que la double signature et la fragmentation au niveau applicatif ont un impact minime sur l'efficacité du processus de résolution, ce qui les rend appropriées pour la période de transition avant la réalisation complète des ordinateurs quantiques.

Contexte et Motivation de la Recherche

1. Problème Central

DNSSEC assure l'authenticité et l'intégrité des réponses DNS par le biais de signatures numériques, mais fait face à un triple dilemme à l'ère quantique:

• Menace quantique: Les ordinateurs quantiques liés à la cryptographie (CRQC) peuvent casser les signatures traditionnelles basées sur la factorisation d'entiers et le logarithme discret en temps polynomial via l'algorithme de Shor
• Immaturité post-quantique: Les signatures post-quantiques sélectionnées par le NIST (FALCON, DILITHIUM, SPHINCS+) n'ont pas encore fait l'objet d'une analyse cryptographique suffisante et peuvent contenir des défauts de conception exploitables par les ordinateurs classiques
• Risque de période de transition: Pendant la « période de transition » entre maintenant et la réalisation complète du CRQC, dépendre uniquement de signatures traditionnelles ou post-quantiques présente des risques de sécurité

2. Importance du Problème

• Le DNS est au cœur de l'infrastructure Internet, toute faille de sécurité pourrait rediriger les utilisateurs vers des serveurs malveillants
• Selon les recommandations de l'ENISA, le simple remplacement des algorithmes cryptographiques pendant la période de transition pourrait réduire la sécurité globale
• Les percées non divulguées du CRQC ou les failles des algorithmes post-quantiques pourraient invalider DNSSEC

3. Limitations des Approches Existantes

• Signatures traditionnelles uniquement: Incapables de résister aux attaques quantiques futures
• Signatures post-quantiques uniquement: Peuvent présenter des vecteurs d'attaque classiques inconnus
• Schémas de fragmentation existants: ARRF utilise des RR non-standard pouvant causer des problèmes de compatibilité avec les middleboxes; QBF ne considère pas le scénario de double signature
• Mécanisme de secours TCP: De nombreux serveurs de noms manquent de support TCP, et TCP est moins léger que UDP

4. Motivation de la Recherche

Adoption d'une stratégie de « double signature » (interface de message détaché):

• Tant qu'une signature est sécurisée, le système global reste sécurisé
• Fournit une protection maximale pour la période de transition
• Nécessite de résoudre le problème de dépassement de taille de message causé par la double signature (>1232B déclenche la fragmentation au niveau IP)

Contributions Principales

1. Implémentation complète de DNSSEC avec double signature: Développement d'une plateforme de test DNSSEC basée sur Docker, utilisant le logiciel BIND9 de qualité commerciale, capable de traiter simultanément les signatures et clés pré-quantiques et post-quantiques dans un seul message de réponse UDP
2. Mécanisme de fragmentation et réassemblage au niveau applicatif: Conception d'un schéma QBF amélioré pour le scénario de double signature:
   • Utilisation de z-bits pour identifier le type d'algorithme post-quantique
   • Utilisation d'un décalage TTL pour maintenir l'ordre original des RR et éviter les erreurs de pointeur de compression
   • Support de toutes les combinaisons pré-quantiques (ECDSA256, RSASHA256) et post-quantiques (FALCON512, DILITHIUM2, SPHINCS+)
3. Modification du code source BIND9: Recherche approfondie et modification du composant résolveur BIND9 pour permettre la vérification de deux signatures avant de marquer la réponse comme authentifiée
4. Évaluation des performances: Analyse empirique démontrant que la double signature a un impact négligeable sur le temps de résolution DNSSEC (<9% d'augmentation), confirmant son applicabilité pour la période de transition

Détails de la Méthode

Définition de la Tâche

Entrée: Requête DNS (par exemple, enregistrement A de test.example.com)
Sortie: Adresse IP avec vérification de double signature
Contraintes:

• Taille du message UDP ≤ 1232B (pour éviter la fragmentation au niveau IP)
• Vérification simultanée des signatures pré-quantiques et post-quantiques
• Maintien de la compatibilité avec l'infrastructure DNS existante

Conception de l'Architecture de Double Signature

1. Génération de Signature (Côté Serveur de Noms)

Utilisation d'une interface de message détaché:

• Génération de deux paires de clés (ZSK et KSK) à l'aide des outils BIND9
• Génération indépendante de deux signatures pour le même RRSet:
  • Signature pré-quantique X (ECDSA256 ou RSASHA256)
  • Signature post-quantique Y (FALCON512/DILITHIUM2/SPHINCS+)
• Les deux RRSIG et DNSKEY sont stockés dans le fichier de zone signé

Exemple (Figure 13):
test0.socratescrc. 3600 IN RRSIG A 13 ... (signature ECDSA)
test0.socratescrc. 3600 IN RRSIG A 249 ... (signature post-quantique)

2. Stratégie de Vérification (Côté Résolveur)

Modification de la logique de vérification BIND9:

• Vérification indépendante des deux signatures
• Acceptation de la réponse uniquement si les deux signatures sont vérifiées
• Fourniture d'une double protection contre les attaques quantiques et classiques

Mécanisme de Fragmentation au Niveau Applicatif

Défi Principal

Taille typique de la réponse avec double signature:

• Réponse d'enregistrement A: ~2500B (combinaison minimale ECDSA+FALCON512)
• Réponse DNSKEY: 4462B (RSASHA256+FALCON512)
• Bien au-delà du seuil de 1232B

Stratégie de Fragmentation

Principes Fondamentaux:

• Les RRSIG et DNSKEY pré-quantiques sont toujours envoyés complètement dans le premier fragment (taille plus petite)
• Les signatures/clés post-quantiques sont fragmentées selon les besoins

Fragmentation de la Réponse d'Enregistrement A (Figure 8a):

1. Le premier fragment contient: En-tête + Question + RRSIG/DNSKEY pré-quantiques complets + partie de RRSIG post-quantique
2. Le résolveur déduit le nombre total de fragments du premier fragment
3. Demande parallèle des fragments restants (format: ?n?domain_name)

Fragmentation de la Réponse DNSKEY (Figure 8b):

• Certaines combinaisons (comme RSASHA256) font que le premier fragment ne peut contenir aucune donnée post-quantique
• Solution innovante:

Méthode d'Identification par Z-bits:

Utilisation des z-bits (3 bits) de RFC 1035:
- Codage du type d'algorithme post-quantique (FALCON/DILITHIUM/SPHINCS+)
- Le résolveur déduit la taille totale selon les z-bits et les RR pré-quantiques reçus

Mécanisme de Décalage TTL:

Problème: Les pointeurs de compression DNS dépendent de l'ordre des RR
Solution: Ajout d'un décalage dans le champ TTL de la réponse DNSKEY
Fonction: Restauration de la position originale des RR lors du réassemblage, évitant l'erreur "bad compression pointer"

Flux de Travail (Figure 10)

Daemon du Serveur de Noms:

1. Interception de la réponse DNS, vérification si la taille >1232B
2. Calcul du nombre de fragments nécessaires
3. Configuration des z-bits (si nécessaire) et du décalage TTL
4. Configuration du flag TC=1, envoi du premier fragment
5. Mise en cache des fragments restants

Daemon du Résolveur:

1. Réception du premier fragment, vérification du flag TC
2. Analyse des z-bits pour déterminer l'algorithme post-quantique
3. Utilisation des informations RR pré-quantiques pour déduire le nombre total de fragments
4. Demande parallèle de tous les fragments restants (?2?test.socrates, ?3?test.socrates...)
5. Après collection de tous les fragments, réassemblage:
   • Utilisation du décalage TTL pour restaurer l'ordre original des RR
   • Réinitialisation du flag TC et d'autres valeurs d'en-tête
6. Transmission du message complet au vérificateur OQS-BIND

Points d'Innovation Technique

1. Compatibilité avec les RR standards: Contrairement à ARRF qui utilise des RR personnalisés, utilisation du format DNS standard pour assurer la compatibilité avec les middleboxes
2. Réutilisation des z-bits: Utilisation innovante des bits d'en-tête sous-utilisés pour résoudre le problème d'information insuffisante dans la réponse DNSKEY
3. Schéma de Décalage TTL: Résolution du conflit entre le mécanisme de compression DNS et le réassemblage de fragments, un problème spécifique au scénario de double signature
4. Demandes de Fragments Parallèles: Le résolveur obtient tous les fragments en parallèle, minimisant la latence
5. Indépendance vis-à-vis de l'Algorithme: Support de toutes les combinaisons d'algorithmes post-quantiques sélectionnés par le NIST et d'algorithmes pré-quantiques courants

Configuration Expérimentale

Architecture de la Plateforme de Test

Infrastructure:

• Instance Amazon EC2 t2.xlarge (4 cœurs Intel Xeon 2.3GHz, 16GB RAM)
• Déploiement containerisé Docker (Docker 25.0.3)
• Composants: Client, Résolveur, Serveur Racine, Serveur Autoritaire

Pile Logicielle:

• OQS-BIND: Version améliorée post-quantique basée sur BIND9
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • Support de FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S (niveau de sécurité 128 bits)
• Daemon QBF modifié: Implémentation de la logique de fragmentation/réassemblage de double signature

Topologie Réseau (Figure 11):

Client → Résolveur → Serveur Racine → Serveur Autoritaire
        ↑                                    ↓
        └────────────────────────────────────┘

Configuration du Jeu de Données

• Noms de domaine de test: 10 enregistrements A (test0.socratescrc - test9.socratescrc)
• Combinaisons de signature: 6 configurations de double signature
  • Pré-quantique: ECDSA256, RSASHA256
  • Post-quantique: FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• Chaîne de confiance: Enregistrements DS correctement configurés, établissement d'une chaîne de confiance complète

Métriques d'Évaluation

1. Temps de résolution: Latence de bout en bout du envoi de la requête à la réception de la réponse vérifiée
2. Nombre de fragments: Fragments nécessaires pour les réponses d'enregistrement A et DNSKEY
3. Surcharge de performance: Augmentation en pourcentage du temps de double signature par rapport à une signature post-quantique unique

Simulation des Conditions Réseau

Utilisation de l'outil Linux tc pour simuler:

• Bande passante: 50 Mbps
• Latence: 10 ms
• Simulation des conditions Internet réelles

Méthodologie Expérimentale

1. Itération des requêtes de résolution pour chaque nom de domaine
2. Enregistrement du temps de résolution pour chaque requête
3. Calcul du temps de résolution moyen sur 10 requêtes
4. Comparaison des performances entre double signature et signature post-quantique unique

Résultats Expérimentaux

Analyse du Nombre de Fragments (Tableau 1)

Découvertes Clés:

• Les combinaisons FALCON et DILITHIUM n'augmentent que d'1 fragment
• Les combinaisons SPHINCS+ n'augmentent pas de fragments supplémentaires (optimisation du daemon supprimant les RR non critiques)
• L'augmentation du nombre de fragments est contrôlable, sans croissance exponentielle

Temps de Résolution Moyen

Combinaisons FALCON (Tableau 2):

Combinaisons DILITHIUM (Tableau 3):

Combinaisons SPHINCS+ (Tableau 4):

Résultats Principaux

1. Surcharge de Performance Acceptable:
   • Toutes les combinaisons de double signature ont une surcharge <9%
   • Bien inférieure à la surcharge du secours TCP (généralement >50%)
2. Configuration Optimale:
   • FALCON+RSASHA: 204.5ms (double signature la plus rapide)
   • DILITHIUM+RSASHA: 220.7ms
   • 14-22% plus rapide que la signature unique SPHINCS+ (245.6ms)
3. RSA Supérieur à ECDSA:
   • La vérification RSA est plus rapide dans toutes les combinaisons
   • Exemple: DILITHIUM+RSA (220.7ms) vs DILITHIUM+ECDSA (225.6ms)
4. Taux de Succès de Vérification de Signature:
   • Toutes les combinaisons de double signature sont correctement vérifiées
   • Le résolveur BIND9 modifié vérifie avec succès les deux signatures (Figure 14)

Découvertes Expérimentales

1. Avantage des Algorithmes Basés sur les Treillis:
   • FALCON et DILITHIUM (basés sur les treillis) ont des tailles de signature plus petites
   • Temps de résolution significativement meilleur que SPHINCS+ (basé sur les hachages)
2. Désavantage de SPHINCS+:
   • Taille de signature maximale (23 fragments pour l'enregistrement A)
   • Le NIST l'a choisi principalement pour éviter une dépendance excessive aux algorithmes basés sur les treillis
   • N'est pas le choix optimal dans le scénario de double signature
3. Fiabilité du Réassemblage de Fragments:
   • Le mécanisme de décalage TTL résout efficacement le problème des pointeurs de compression
   • Le schéma z-bits transmet précisément les informations d'algorithme
   • Aucune perte de message ou échec de vérification
4. Gain de Sécurité:
   • La double signature fournit un mécanisme « fail-safe »
   • Même si l'algorithme basé sur les treillis est compromis, RSA/ECDSA fournit toujours la sécurité classique
   • Même si l'ordinateur quantique est réalisé, l'algorithme post-quantique fournit une protection

Travaux Connexes

Recherche DNSSEC Post-Quantique

1. Müller et al. (2020):
   • Analyse des exigences des candidats du troisième tour du NIST pour DNSSEC
   • N'a pas considéré le schéma de double signature
2. Beernink (2022):
   • Proposition de transmission hors bande de grandes clés
   • N'a pas résolu le problème de taille de message de double signature
3. Goertzen & Stebila (2022) - ARRF:
   • Fragmentation au niveau applicatif sur demande
   • Introduction du pseudo-RR RRFRAGS (non-standard)
   • Risque d'attaques par épuisement de mémoire
4. Rawat & Jhanwar (2024) - QBF:
   • Fragmentation basée sur QName, utilisation de RR standards
   • Demandes de fragments parallèles améliorant l'efficacité
   • Ne supporte pas la double signature

Comparaison des Contributions

Recherche sur les Combinateurs Cryptographiques

• L'ENISA (2022) recommande l'utilisation de systèmes cryptographiques hybrides pendant la période de transition
• Cet article est le premier travail implémentant et évaluant la double signature dans DNSSEC
• Utilisation d'une interface de message détaché (intégration plus facile)

Conclusion et Discussion

Conclusions Principales

1. Faisabilité Technique: La double signature DNSSEC est entièrement réalisable sur l'infrastructure existante, sans modification au niveau du protocole
2. Performance Acceptable: Surcharge de performance <9%, bien inférieure au secours TCP, n'affectant pas significativement l'expérience utilisateur
3. Amélioration de la Sécurité: Fournit une double protection contre les attaques quantiques et classiques, appropriée pour le déploiement en période de transition
4. Meilleures Pratiques: Recommandation d'utiliser la combinaison FALCON ou DILITHIUM avec RSA, équilibrant sécurité et performance

Limitations

1. Échelle de Test Limitée:
   • Test uniquement sur une seule instance EC2
   • Absence de simulation de déploiement Internet à grande échelle
   • Manque de test sur le trafic réseau réel
2. Conditions Réseau Simplifiées:
   • Simulation uniquement de 50Mbps de bande passante et 10ms de latence
   • Non-considération de la perte de paquets, de la gigue et d'autres conditions complexes
   • Absence de test dans des environnements MTU différents
3. Surcharge du Daemon:
   • Implémentation de la logique de fragmentation/réassemblage dans un daemon indépendant
   • La communication inter-processus peut introduire une latence supplémentaire
   • Absence d'intégration directe au noyau BIND9
4. Compatibilité avec les Middleboxes:
   • Absence de test complet du comportement des pare-feu, NAT et autres middleboxes
   • La réutilisation des z-bits peut causer des problèmes dans certaines implémentations
5. Impact sur la Mise en Cache:
   • Absence d'analyse de l'impact de la fragmentation sur l'efficacité du cache DNS
   • Plusieurs fragments peuvent augmenter la complexité du cache
6. Analyse de Sécurité Insuffisante:
   • Absence de preuve de sécurité formelle
   • Absence d'évaluation de la robustesse contre les attaques DoS
   • Absence d'analyse des risques de canal auxiliaire du réassemblage de fragments

Directions Futures

1. Intégration Directe dans BIND9:
   • Intégration de la logique de fragmentation au noyau BIND9
   • Réduction attendue du temps de résolution
2. Test de Déploiement à Grande Échelle:
   • Essais pilotes sur l'infrastructure DNS réelle
   • Évaluation de la compatibilité avec diverses middleboxes
3. Optimisation du Choix d'Algorithme:
   • Sélection dynamique de combinaisons d'algorithmes selon le type de requête
   • Exploration de stratégies de fragmentation adaptatives
4. Promotion de la Standardisation:
   • Soumission de brouillons à l'IETF
   • Promotion de la double signature comme pratique standard en période de transition
5. Amélioration de la Sécurité:
   • Ajout de mécanismes de protection DoS
   • Recherche sur la défense contre les attaques de synchronisation du réassemblage de fragments

Évaluation Approfondie

Points Forts

1. Positionnement Précis du Problème:
   • Identification claire du dilemme de sécurité de la période de transition
   • La stratégie de double signature est conforme aux recommandations d'autorités comme l'ENISA
   • Résolution des obstacles techniques clés du déploiement réel
2. Solution Technique Complète:
   • Les z-bits et le décalage TTL sont des solutions d'ingénierie innovantes
   • Équilibre entre performance, compatibilité et sécurité
   • Détails d'implémentation suffisants (modifications du code source, conception du daemon)
3. Conception Expérimentale Raisonnable:
   • Utilisation du logiciel BIND9 de qualité commerciale augmentant l'utilité pratique
   • Test de toutes les combinaisons d'algorithmes courants
   • Simulation des conditions réseau conforme aux scénarios réels
4. Résultats Convaincants:
   • Données de performance claires (<9% de surcharge)
   • Vérification de la correction de toutes les combinaisons
   • Recommandations claires de déploiement (FALCON/DILITHIUM+RSA)
5. Valeur d'Ingénierie Élevée:
   • Basé sur OQS-BIND open-source, bonne reproductibilité
   • Déploiement containerisé Docker facilitant la promotion
   • Fourniture d'un chemin viable pour le déploiement réel

Insuffisances

1. Manque d'Analyse Théorique:
   • Absence de preuve de sécurité formelle du schéma de double signature
   • Absence de discussion sur la force cryptographique de la combinaison de signatures
   • Manque de justification rigoureuse de l'hypothèse « une signature échoue, l'autre reste sûre »
2. Portée d'Évaluation Limitée:
   • Seulement 10 noms de domaine de test, petit échantillon
   • Absence de test en scénarios de charge élevée et haute concurrence
   • Manque de test de stabilité à long terme
3. Comparaison Insuffisante avec les Approches Existantes:
   • Absence de comparaison directe des performances avec le secours TCP
   • Absence d'évaluation des avantages par rapport aux schémas alternatifs comme EDNS(0) padding
   • Manque d'analyse comparative de sécurité par rapport aux déploiements purs FALCON, DILITHIUM
4. Considérations Pratiques Incomplètes:
   • Absence de discussion sur la complexité de la gestion des clés (deux ensembles de clés)
   • Absence d'analyse du coût de mise à niveau de l'infrastructure DNSSEC existante
   • Manque de test de compatibilité rétroactive (ancien résolveur)
5. Écriture Améliorable:
   • Certains détails techniques trop verbeux (Section 2 sur les bases du DNS)
   • Les figures pourraient être plus claires (Figures 8, 10 complexes)
   • Absence de pseudocode d'algorithme

Impact

Contribution au Domaine:

• Pionnière: Premier travail implémentant et évaluant la double signature DNSSEC
• Opportune: Réponse opportune au processus de normalisation PQC du NIST
• Pratique: Fournit une solution de transition immédiatement déployable

Valeur Pratique:

• Court terme: Fournit aux opérateurs DNS une solution d'amélioration de sécurité en période de transition
• Moyen terme: Fournit des données empiriques pour la normalisation IETF
• Long terme: Fournit une référence pour la transition quantique-sûre d'autres protocoles

Reproductibilité:

• ✓ Basé sur des logiciels open-source (OQS-BIND)
• ✓ Description d'implémentation détaillée
• ✗ Code non publié (aucun lien GitHub mentionné dans l'article)
• ✓ Déploiement containerisé Docker réduisant la difficulté de reproduction

Impact Potentiel:

• Peut promouvoir l'adoption de la stratégie de double signature par la communauté DNS
• Fournit une référence pour la stratégie de fragmentation d'autres protocoles au niveau applicatif (TLS, SSH)
• Aide à accélérer le déploiement réel de la cryptographie post-quantique

Scénarios d'Application

Scénarios d'Application Idéaux:

1. DNS d'Infrastructure Critique: Noms de domaine des secteurs financier et gouvernemental avec exigences de sécurité extrêmes
2. Déploiement en Période de Transition: 2025-2030 lorsque la menace CRQC s'intensifie mais les algorithmes post-quantiques nécessitent toujours une validation
3. Cibles de Haute Valeur: Organisations facilement ciblées par des attaquants au niveau national

Scénarios Non Applicables:

1. Environnements aux Ressources Limitées: Appareils IoT, systèmes embarqués (surcharge de calcul et de stockage)
2. Exigences de Faible Latence: Systèmes de communication en temps réel (8% de latence supplémentaire peut être inacceptable)
3. Ère Post-Quantique: Une fois les algorithmes post-quantiques complètement matures, la nécessité de la double signature diminue

Recommandations de Déploiement:

• Priorité au déploiement sur les serveurs racine et les serveurs TLD
• Utilisation de la combinaison FALCON+RSA ou DILITHIUM+RSA
• Coexistence avec l'infrastructure DNSSEC existante (mise à niveau progressive)
• Établissement de mécanismes de surveillance pour suivre les performances et la sécurité

Références Clés

1. Shor (1994): "Algorithms for quantum computation" - Fondement théorique de la menace quantique
2. Normalisation PQC du NIST: Spécifications des algorithmes FALCON, DILITHIUM, SPHINCS+
3. RFC 4034: Spécification des enregistrements de ressources DNSSEC
4. RFC 6891: Mécanisme d'extension EDNS(0)
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" - Base politique de la stratégie de double signature
6. Goertzen & Stebila (2022): Schéma de fragmentation ARRF
7. Rawat & Jhanwar (2024): Schéma de fragmentation QBF (base directe de cet article)

Résumé

Cet article aborde le défi unique de la période de transition quantique-sûre de DNSSEC en proposant une solution de double signature réalisable sur le plan de l'ingénierie. Grâce à une conception ingénieuse de la fragmentation au niveau applicatif (identification par z-bits, décalage TTL), il résout avec succès le problème de dépassement de taille de message causé par la double signature. Les expériences démontrent que la surcharge de performance est contrôlable (<9%), appropriée pour le déploiement réel. Il s'agit d'un cas typique de « recherche pilotée par l'ingénierie », où bien que l'innovation théorique soit limitée, la valeur d'ingénierie est significative, fournissant à la communauté DNS une solution de transition opportune et pratique. La valeur principale de l'article réside dans la première implémentation et validation, plutôt que dans une percée théorique, ce qui est tout aussi important dans le domaine de la cryptographie appliquée. Il est recommandé aux auteurs de compléter les travaux ultérieurs par une analyse de sécurité formelle et des tests de déploiement à grande échelle, et de promouvoir l'open-source du code pour augmenter l'impact.