Résumé

  • Les DNS Cookies transforment un premier aller-retour en indice de joignabilité : une requête ultérieure portant le bon couple de jetons est plus difficile à fabriquer depuis un chemin extérieur.
  • RFC 7873 a défini l’échange ; RFC 9018 a ensuite imposé un Server Cookie version 1 interopérable afin que des nœuds anycast utilisant des logiciels différents puissent valider le même état.
  • Ce mécanisme n’établit ni identité ni confidentialité. Un observateur sur le chemin voit les jetons, un NAT regroupe plusieurs clients derrière une même adresse, et les contrôles de débit restent nécessaires.

Le premier paquet n’arrive avec aucun compte, aucun certificat et aucune clé négociée. Son adresse source peut être exacte ou usurpée. Le client place dans l’option EDNS COOKIE un Client Cookie de huit octets. Si le serveur prend en charge le mécanisme, il renvoie cette valeur accompagnée de son propre Server Cookie. Lors de la requête suivante, le client présente les deux.

Ce second échange contient un fragment d’histoire. Le Server Cookie dépend du Client Cookie, de l’adresse apparente du client et d’un secret détenu par le serveur. Un attaquant hors chemin peut écrire l’adresse d’une victime dans un en-tête IP, mais il ne devrait pas avoir vu la réponse envoyée à cette adresse. Il lui manque donc le jeton attendu. Le serveur obtient un indice qu’il a déjà communiqué avec cette combinaison d’adresse et de cookie ; le client, de son côté, peut écarter une réponse qui ne lui rend pas le Client Cookie prévu.

La nuance est essentielle. Le cookie ne dit pas qui se trouve derrière l’adresse. Une passerelle domestique, un NAT d’opérateur ou un pare-feu d’entreprise peuvent agréger de nombreux hôtes. Une machine compromise au bon endroit reste capable d’abus. Un observateur situé sur le chemin peut copier un cookie visible et le réutiliser pendant sa durée de validité. Il n’y a ni chiffrement de la question, ni attestation de l’organisation, ni substitution à DNSSEC. Il existe seulement une preuve faible que le chemin de retour a déjà fonctionné.

Cette preuve répondait à un défaut concret du DNS sur UDP. Une petite question portant une adresse source falsifiée pouvait provoquer une réponse beaucoup plus grande vers une victime. Une requête forgée pouvait aussi imposer à un résolveur des recherches ou des validations DNSSEC coûteuses. Dans l’autre sens, des réponses aveugles pouvaient tenter de gagner la course et d’empoisonner le cache.

DNSSEC protège l’authenticité des données ; TSIG offre une authentification de transaction plus forte mais suppose une gestion de clés ; l’aléa des ports et identifiants complique les devinettes ; la limitation de débit réduit l’amplification. Les DNS Cookies complètent cet ensemble par un état léger, recalculable, sans table client côté serveur.

Publié en mai 2016, RFC 7873 a attribué le code 10 à l’option COOKIE. En l’absence de jeton serveur connu, l’option ne contient que les huit octets du Client Cookie. Après apprentissage, elle contient également un Server Cookie, dont la spécification initiale autorisait une taille de huit à trente-deux octets. Sa fabrication exacte restait privée à chaque mise en œuvre. Le serveur pouvait vérifier le jeton à partir de la source, du Client Cookie et de son secret, sans mémoriser chaque client.

La machine d’état tolère un déploiement progressif. Un serveur qui ignore les DNS Cookies ignore aussi l’option. Un serveur compatible recevant seulement un Client Cookie peut, selon sa politique, abandonner la requête, répondre BADCOOKIE ou la traiter normalement ; s’il répond, il fournit le Server Cookie qui permettra le prochain état. Une option mal formée entraîne FORMERR. Un cookie serveur périmé ou invalide est traité comme absent. Un cookie valide permet d’assouplir les défenses visant précisément l’usurpation de source UDP, pas d’accorder une confiance générale.

BADCOOKIE constitue ainsi une transition, pas seulement un échec. La réponse restitue le Client Cookie attendu et fournit une nouvelle valeur serveur pour la tentative suivante. Si cette valeur fraîche échoue immédiatement, le client peut passer à TCP. Une répétition de ce scénario peut signaler autre chose qu’une attaque : les membres d’un service anycast peuvent ne pas partager le même secret ou la même méthode de calcul.

Le NAT explique pourquoi les deux composantes sont nécessaires. Si le Server Cookie ne dépendait que de l’adresse publique, un hôte derrière la passerelle pourrait obtenir un jeton utilisable par tous les autres. L’inclusion du Client Cookie distingue les flux tout en évitant un état individuel côté serveur. La granularité reste celle que le réseau expose ; ce n’est toujours pas une identité personnelle.

L’anycast a révélé la faiblesse historique la plus importante. Une adresse de service peut conduire deux requêtes successives vers des machines distinctes et des logiciels différents. RFC 7873 recommandait un secret partagé, mais laissait libre la transformation des entrées en cookie. Deux produits pouvaient donc partager le même secret et produire des valeurs incompatibles. Un changement de route suffisait à faire paraître le client fautif.

RFC 9018, publié en avril 2021, a normalisé le Server Cookie version 1. Ses seize octets réunissent un octet de version, trois octets réservés, quatre octets d’horodatage et huit octets issus de SipHash-2-4. Avec le Client Cookie, l’option complète mesure exactement vingt-quatre octets. Le hachage couvre le Client Cookie, les champs de structure, l’adresse IP du client et le secret serveur ; l’adresse participe au calcul sans être copiée dans le jeton.

L’horodatage borne la répétition. Le texte recommande d’accepter une valeur datant de moins d’une heure, de tolérer cinq minutes d’avance pour les écarts d’horloge et de renouveler un cookie vieux de plus d’une demi-heure. Il s’agit de recommandations, non de mesures universelles. Elles montrent surtout que l’indice doit expirer. L’observateur sur le chemin voit aussi la fenêtre pendant laquelle sa copie peut servir.

La rotation du secret devient alors une opération collective. Le nouveau secret doit d’abord être distribué à tous les nœuds pendant qu’ils émettent encore avec l’ancien et valident les deux. Ils commencent ensuite à émettre avec le nouveau sans cesser immédiatement d’accepter l’ancien. Celui-ci n’est retiré qu’après la période de recouvrement. L’interopérabilité dépend donc autant des horloges, de la distribution et de la phase de déploiement que de la fonction cryptographique.

RFC 9018 a aussi révisé le Client Cookie : soixante-quatre bits d’entropie par adresse de serveur, et aucune réutilisation après un changement d’adresse du client. Cette discipline réduit le risque qu’un identifiant stable suive un appareil entre plusieurs réseaux. Un hôte derrière un NAT ne sait toutefois pas toujours que l’adresse publique de la passerelle a changé ; cette limite demeure explicitement hors du mécanisme.

L’histoire des DNS Cookies est donc celle d’une preuve ajustée à sa portée. Le premier échange ne révèle aucune intention. Il fabrique un jeton qui rend plus coûteuse, depuis l’extérieur du chemin, la fausse affirmation d’avoir cette adresse source. RFC 7873 a formulé ce compromis ; RFC 9018 l’a rendu praticable dans un parc anycast hétérogène. L’autorité réelle reste dans les politiques de réponse, la durée de réutilisation, les horloges et la garde coordonnée des secrets.

Sources