Résumé

  • Le protocole DNS considère les lettres ASCII comme identiques quelle que soit leur casse, tout en conservant souvent la graphie reçue. Le projet DNS-0x20 voulut transformer cette copie exacte en élément d’identité d’une transaction.
  • Le gain dépendait du nombre de lettres, de la fidélité des serveurs et intermédiaires, du nettoyage avant décompression et d’un repli résistant à la dégradation. Il ne prouvait ni l’origine ni l’intégrité des données et le projet expira sans devenir une RFC.

La réponse devait se souvenir d’un détail inutile

Un serveur faisant autorité reçoit une question dont les lettres ont été mises aléatoirement en majuscules ou en minuscules. Pour chercher l’enregistrement, il replie la casse : le motif ne crée aucun nouveau nom. Mais le résolveur qui reçoit la réponse ne juge pas seulement l’équivalence du nom. Il vérifie si la section Question reproduit le motif exact qu’il vient d’inventer.

Le même objet passe ainsi deux épreuves différentes. L’une demande ce que le nom désigne. L’autre demande si une réponse correspond à cette requête encore ouverte. Un faussaire hors chemin peut connaître le nom recherché sans connaître la façon éphémère dont il a été écrit.

La proposition dite DNS-0x20 ne cherchait donc pas à rendre la casse significative dans le DNS. Elle utilisait sa représentation comme un état local, valable seulement entre l’envoi et le retour d’une question.

Une ambiguïté volontaire depuis 1987

La RFC 1035 impose des comparaisons insensibles à la casse dans les parties officielles du protocole. Deux noms qui ne diffèrent que par A-Z ou a-z sont identiques. Pourtant, elle demande aussi de préserver la casse originale lorsque cela est possible et d’en limiter la perte.

Ce partage des rôles servait l’interopérabilité. La casse ne devait pas fragmenter l’espace de noms, mais une implantation pouvait conserver la forme saisie pour l’affichage. L’identité était normalisée, pas nécessairement tous les octets transportés.

La RFC 4343 précisa ensuite que cette règle porte sur les lettres ASCII. Elle ne justifie pas une conversion linguistique générale et ne remplace pas le traitement IDNA. Surtout, la préservation demeure une recommandation conditionnelle. Une base qui réunit plusieurs graphies ne peut en retenir qu’une, et la compression des noms peut faire dépendre l’écriture rendue d’une autre position du message.

DNS-0x20 s’est glissé dans cet intervalle : la casse n’était pas un identifiant, mais elle n’était pas toujours détruite.

Le bit 0x20 comme état jetable

Le projet Internet de mars 2008, Use of Bit 0x20 in DNS Labels, proposait de choisir au hasard le bit qui sépare les majuscules et les minuscules ASCII pour chaque lettre du QNAME. Toutes les combinaisons restaient équivalentes pour le serveur. Le résolveur, lui, pouvait les distinguer pendant la durée de la transaction.

Le mécanisme supposait que le répondant recopie exactement la section Question. Les auteurs rapportaient que les grands serveurs testés en 2008 le faisaient, même si les spécifications ne l’exigeaient pas alors. Ils avaient aussi observé quelques logiciels qui remettaient tout en minuscules. Leur constat était une mesure datée, non une garantie universelle.

Dans la RFC 5452, une réponse acceptable doit correspondre à plusieurs éléments de la requête : question, identifiant, adresses, ports, classe et type. Un identifiant de transaction de 16 bits, même bien aléatoire, reste un espace fini; la diversification du port source l’élargit. Le motif de casse devait ajouter d’autres choix que l’attaquant aveugle aurait à deviner simultanément.

Rien de cela n’authentifiait le RRset. Une réponse qui devine tous les éléments pouvait encore gagner la course. DNS-0x20 augmentait un coût probabiliste; il ne créait ni signature ni autorité.

La longueur du nom devenait une variable de sécurité

Chaque lettre ASCII admissible apportait au plus un bit. Les chiffres et les traits d’union n’en apportaient aucun. Un nom court et peu alphabétique disposait de peu de motifs; un nom long et riche en lettres en offrait davantage. Le projet assumait expressément cette inégalité.

Un indicateur binaire « 0x20 activé » aurait donc peu de sens. La contribution effective varie à chaque question. Elle dépend du nombre de lettres, de la qualité du tirage et du nombre de choix qui survivent réellement au trajet aller-retour.

Les étiquettes internationalisées ne permettent pas d’additionner naïvement des bits. La règle ASCII de la RFC 4343 et les transformations IDNA appartiennent à des couches différentes. Appliquer les habitudes typographiques d’une langue à une valeur sur le fil pourrait modifier le nom au lieu de fournir un défi compatible.

Un intermédiaire pouvait être correct et destructeur

Un relais DNS qui met toutes les questions en minuscules peut livrer le bon RRset au bon demandeur. Selon la sémantique fondamentale du DNS, il n’a pas changé le nom. Selon le contrat 0x20, il a effacé l’information que le demandeur voulait revoir.

Cette divergence transforme une habitude d’implémentation en dépendance. Le résolveur produit le défi, mais le serveur faisant autorité, les relais et les boîtiers du chemin déterminent s’il existe encore au retour. Aucun acteur ne contrôle seul la propriété de bout en bout.

Une différence de casse ne dit pas pourquoi elle est apparue. Elle peut signaler une contrefaçon, une normalisation constante, un dispositif intermédiaire ou un défaut. Le projet recommandait de journaliser et d’essayer d’autres adresses faisant autorité. Il ne donnait pas à une majuscule modifiée la valeur d’une preuve d’attaque.

La décompression venait après l’effacement

La discipline la plus subtile concernait le cache. Dans un paquet DNS, des pointeurs de compression peuvent renvoyer depuis les sections Réponse, Autorité ou Additionnelle vers le nom placé dans la question. Si le résolveur décompresse ces noms alors que le motif aléatoire est encore présent, il risque de copier cette casse transitoire dans son cache et dans des réponses ultérieures.

Le projet demandait donc de conserver le nom d’origine, de vérifier le motif reçu, puis de restaurer la question avant de décompresser les autres sections. L’état de transaction devait disparaître avant que le message n’alimente un état durable.

Cette séquence interdit de réduire 0x20 à une astuce de générateur aléatoire. L’invention d’un nonce dans un espace de représentation oblige à définir sa destruction. Sans cette frontière, le mécanisme exporte son aléa vers des utilisateurs qui n’en faisaient pas partie.

Le repli pouvait devenir une commande distante

Refuser toute réponse dont la casse diffère préserve le défi, mais peut rendre un serveur normalisant la casse inutilisable. Désactiver le contrôle dès le premier échec restaure la disponibilité, mais permet potentiellement à un adversaire de provoquer le retour à un mode plus faible.

Le projet envisageait une inférence plus prudente : essayer les autres serveurs faisant autorité, puis répéter des séquences complètes avec de nouveaux identifiants et un ordre différent. Si les autres éléments aléatoires revenaient correctement plusieurs fois alors que la casse était systématiquement modifiée, le résolveur pouvait conclure plus raisonnablement à une incompatibilité.

Cette prudence consommait du temps et des requêtes. Les serveurs qui repliaient la casse pouvaient recevoir plusieurs fois le trafic ordinaire. Le générateur aléatoire exposait aussi davantage de sorties. La disponibilité, la charge et la résistance à la dégradation formaient donc le véritable plan de contrôle.

DNSSEC efface ce que 0x20 voulait préserver

La RFC 4034 exige, pour la forme canonique utilisée par DNSSEC, de développer les noms compressés et de convertir les lettres ASCII majuscules pertinentes en minuscules. Une signature doit porter sur une représentation que tous les validateurs reconstruisent à l’identique.

La comparaison est éclairante. DNS-0x20 voulait conserver une variation aléatoire pendant un aller-retour. DNSSEC supprime la variation afin d’authentifier un RRset canonique. Le premier rend une devinette plus coûteuse; le second peut établir une chaîne d’autorisation cryptographique. Une question bien recopiée n’est pas une donnée signée.

Ce que prouve un projet arrivé à expiration

Le document DNS-0x20 expira en septembre 2008. Il n’est ni une RFC finale ni un recensement des déploiements actuels. Sa place dans l’histoire vient de la question qu’il formula avec précision.

Un protocole peut déclarer une distinction insignifiante pour l’identité tout en laissant sa représentation disponible. Cette marge peut servir de ressource défensive, à condition de compter ses bits, d’identifier ceux qui doivent la préserver, de traiter le repli comme un choix de sécurité et de nettoyer l’état avant le cache.

Les majuscules n’ont jamais obtenu le pouvoir de nommer. Durant une requête, elles pouvaient seulement constituer une question que la réponse devait répéter sans la connaître à l’avance.

Sources et limites

Cette analyse repose sur la RFC 1035, la RFC 4343, la RFC 5452, la RFC 4034 et le projet Internet DNS-0x20 de mars 2008. Les essais cités dans le projet décrivent son époque; ces textes ne mesurent ni les réglages par défaut ni la compatibilité mondiale d’aujourd’hui.