Le système d'authentification du
L'algorithme utilisé dans une signature DNSSEC apparait dans
l'enregistrement
% dig +dnssec SOA fr.
...
;; ANSWER SECTION:
fr. 172800 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. 2222283656 3600 1800 3600000 5400
fr. 172800 IN RRSIG SOA 8 1 172800 20130814151003 20130615141003 62646 fr. FSSGO0iZ6OBoSUE12Q/NYOU2f3AMNbOf/b4FoC48F8f5gDfSNpJStZF7 zGsN51+zFE3FCucNDw4cQMY8YqBeu6BN5IG4StqAjEp+3FqLYSzyUu4s tZY8GnLa9ZzJCTf6dGT0CE2JbEzc705hc6X6I7DDxqwrzzpj23F/Rg9 PEk=
...
La signature est faite avec l'algorithme 8,
% dig +dnssec SOA ecdsa.isc.org
...
;; ANSWER SECTION:
ecdsa.isc.org. 3600 IN SOA ns-int.isc.org. hostmaster.isc.org. 2013052903 7200 3600 604800 3600
ecdsa.isc.org. 3600 IN RRSIG SOA 14 3 3600 20130712033157 20130612023157 30631 ecdsa.isc.org. o+Q1WDDeiCM3z2b793Ni/FtMT223gJ/1Lr+RWOgPJLVxB+AlLKyKvLOs vWRBqUjwYeKE4Dx/ZUSIx8eVzOUt5g6HvBuGaYX/camsYn9ocuTp6J+w J2Fn69Qi6/WbhAa4
...
Elle est fait avec 14,
Actuellement, les serveurs faisant autorité pour une zone ne savent
pas quels algorithmes sont compris par les résolveurs qui les
interrogent. Le serveur qui fait autorité envoie toutes les signatures
qu'il connait et le résolveur se débrouille. Reprenons le cas de
Le principe est d'utiliser trois nouvelles options
L'encodage d'une option EDNS se fait en trois champs, le code sur deux octets (5, 6 ou 7 ici), la longueur des données sur deux octets et les données. Ici, les données consistent en une liste d'algorithmes, un octet pour chacun, dans un ordre quelconque (l'ordre n'exprime pas une préférence). Par exemple, un résolveur validant qui accepte RSA-SHA1, RSA-SHA256 et ECDSA-SHA384 encodera un DAU avec les octets {5, 0, 3, 5, 8, 14}. En pratique, le RFC estime que les trois options toutes ensemble devraient prendre de 22 à 32 octets (en comptant 6 à 10 algorithmes de signature, plus quelques uns pour la condensation).
Bon, et une fois le format défini, on s'en sert comment ? Pour les clients (les résolveurs), c'est en sections 3 et 4 du RFC. Si le client valide, il ajoute une, deux ou trois des nouvelles options dans sa requête. Sinon, il ne doit pas les utiliser.
Si le résolveur
valide et qu'il reçoit une requête ayant déjà une de ces options, il
doit ajouter ses propres algorithmes. La liste finale sera donc
l'union des deux. Un simple relais (
Et le serveur faisant autorité ? C'est en section 5. Le point
important est qu'il ne
Revenons aux administrateurs d'une zone qui voudraient mesurer le déploiement d'un nouvel algorithme cryptographique. Que faire si les clients n'envoient pas cette option ? La section 6 conseille de les considérer comme du vieux logiciel, n'ayant pas les nouvelles options, ni les nouveaux algorithmes. C'est un peu court, à mon avis, car on peut aussi imaginer qu'il y aura des résolveurs récents qui n'enverront pas cette option, peut-être par souci de discrétion (ce point est également couvert dans la section 7, consacrée aux risques de sécurité).
Il ne semble pas exister beaucoup de mises en œuvre de ce RFC. Par
exemple,
: type OPT
Name:
Depuis r50840, Wireshark a le code nécessaire et
on n'a plus qu'à patienter que cela arrive dans une version officielle.
L'examen des requêtes envoyées à un gros serveur de noms ne montrait, au moment de la sortie du RFC, pratiquement pas d'utilisation de cette option.
Trois ans après la
publication du RFC, une discussion lors d'une réunion OARC semblait indiquer qu'il
n'avait connu aucun déploiement et devait être considéré comme un
échec. Mais en juin 2020,