Ce RFC marque l'arrivée d'un nouvel algorithme de signature dans les
enregistrements DNSSEC, algorithme portant le numéro
23. Bienvenue au GOST R 34.10-2012 (alias ECC-GOST12), algorithme
russe, spécifié en anglais dans le RFC 7091, une légère mise à jour de GOST R 34.10-2001.
La liste des algorithmes DNSSEC est un registre à l'IANA, https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1. Elle
comprend désormais GOST R 34.10-2012 (qui succède au R 34.10-2001 du
RFC 5933). Notez que GOST désigne en fait une
organisation de
normalisation, le terme correct serait donc de ne jamais
dire « GOST » tout court, mais plutôt « GOST R 34.10-2012 » pour
l'algorithme de signature et « GOST R 34.11-2012 » pour celui de
condensation,
décrit dans le RFC 6986 (voir la section 1 de notre RFC 9558).
La section 2 décrit le format des enregistrements
DNSKEY avec GOST, dans lequel
on publie les clés GOST R 34.10-2012. Le champ Algorithme vaut 23,
le format de la clé sur le réseau suit le RFC 7091. GOST
est un algorithme à courbes elliptiques, courbes décrites par Q
= (x,y). Les 32 premiers octets de la clé sont x et les 32 suivants
y (en petit-boutien,
attention, contrairement à la majorité des protocoles Internet).
Parmi les bibliothèques cryptographiques existantes, au moins
OpenSSL met en œuvre GOST R 34.10-2012 (testé
avec la version 3.3.2). Voir RFC 9215 pour de
l'aide à ce sujet. Sinon, on trouve parfois seulement l'ancienne
version dans certains logiciels et certaines bibliothèques.
La section 2.2 donne un exemple de clé GOST publiée dans le DNS,
je n'ai pas trouvé d'exemple réel dans la nature, même en
.ru.
La section 3 décrit le format des enregistrements RRSIG, les signatures (avec un
exemple). On suit les RFC 5958 et RFC 7091.
Attention, une particularité de GOST fait que deux signatures des
mêmes données peuvent donner des résultats différents, car un
élément aléatoire est présent dans la signature.
La section 4
décrit le format des enregistrements DS pour GOST. La clé publique de
la zone fille est condensée par GOST R 34.11-2012, algorithme de
numéro
5.
Les sections 5 et 6 couvrent des questions pratiques liées au
développement et au déploiement de systèmes GOST, par exemple un
rappel sur la taille de la clé (512 bits) et sur celle du condensat
cryptographique (256 bits).
GOST peut se valider avec Unbound si la bibliothèque de
cryptographie utilisée gère GOST. Et, comme indiqué plus haut, ce ne
sera sans doute que l'ancienne version, celle du RFC 5933. Pour les programmeurs Java, DNSjava a le dernier GOST depuis la
version 3.6.2. Pour le statut (recommandé ou non) de l'algorithme
GOST pour DNSSEC, voir le RFC 8624. En
Python,
dnspython en version 2.7.0 n'a que l'ancien
algorithme.
RFC 8594: The Sunset HTTP Header Field
- 27 février -
Un nouvel en-tête HTTP (et un nouveau type de lien) fait son apparition avec ce RFC : Sunset: (coucher de soleil) sert à indiquer la date où la (...)
Si Einstein avait su
- 24 février -
Alain Aspect raconte dans ce livre l'histoire des expériences qu'il a menées dans les années 1970-1980 et qui ont prouvé la violation des inégalités (...)
Recommandations DNS lorsqu'on change d'adresse IP
- 21 février -
Aujourd'hui, avec les mécanismes d'allocations d'adresses IP existants (cf. RFC 7020), il est relativement fréquent d'avoir à changer son adresse (...)
RFC 9609: Initializing a DNS Resolver with Priming Queries
- 12 février -
Un résolveur DNS ne connait au début, rien du contenu du DNS. Rien ? Pas tout à fait, il connait une liste des serveurs de noms faisant autorité (...)
Faut-il critiquer l'IA ?
- 9 février -
Plusieurs organisations françaises viennent de signer un appel critique vis-à-vis de l'IA, dans le contexte du sommet IA du gouvernement. Alors que (...)
