Mon blog

Dans ce court mais très percutant essai, Leïla Slimani commence par se demander pourquoi elle ne parle pas arabe, puis s'attaque aux politiques identitaires et défend la pluralité et l'égalité des langues (ainsi que la liberté de leurs locuteurs et locutrices).

Petite, l'auteure, dans son Maroc natal, parlait darija. Mais à la maison (famille assez riche et éduquée), c'était le français. Et les cours d'arabe classique, donnés par des enseignants rétrogrades et ennuyeux, n'attiraient pas. Résultat, aujourd'hui (elle vit en France), elle ne peut plus parler arabe et le regrette.

Slimani dénonce donc la hiérarchisation des langues, le fait que certaines langues étaient vues comme inférieures, moins intéressantes et donc pas ou mal enseignées. Et elle en profite pour défendre l'idée de langues vivantes, qui changent et ne sont pas tenues aux oukases (tiens, est-ce un mot français ?) d'institutions réactionnaires. C'est ainsi qu'elle défend les textes d'Aya Nakamura ou, plus exactement, le droit de la chanteuse à écrire comme elle le souhaite.

Mais surtout, l'auteure lance un « assaut contre la frontière » en dénonçant les politiques identitaires ou l'assignation à une identité unique, et en prônant l'universalité, que permet le pluralisme des langues. « Combien de fois m'a-t-on demandé si je me sentais plus arabe ou plus française. »

PS : la question de l'enseignement de l'arabe en France est un vieux sujet et je retrouve un article que j'avais fait en 2020.

Le titre original « Amour et sexe dans la Rome antique » résume mieux ce livre que la ridicule traduction française. Mais ne lisant pas l'italien, j'ai dû passer par cette traduction. Donc, ce livre est un récit de plusieurs aspects de la sexualité dans la Rome de l'Antiquité.

Comme dans les précédents livres de cet excellent vulgarisateur qu'est Alberto Angela, le récit est très vivant, les personnages attachants et, vu le sujet choisi (amour et sexe…), le livre a certainement de quoi capter l'attention. Comment embrassait-on à Rome ? Comment draguait-on ? Quelles étaient les positions utilisées ? D'un côté, il y avait une certaine liberté des mœurs (davantage qu'avec le christianisme ultérieur), de l'autre, c'était quand même une société très machiste (et violente)… D'autant plus qu'on la connait surtout par des textes d'auteurs masculins. Mais, bon, j'en profite pour placer une image récupérée sur Wikimedia Commons car il n'y a pas assez d'images érotiques sur ce blog :

Mais je suis un peu resté sur ma faim : plusieurs des éléments des précédents livres de cet auteur ont été réutilisés, et il n'y a pas assez de nouveautés pour moi. Je conseillerai aux lecteurices potentiel·les, qui s'intéressent aux différents aspects de la vie des Romains de l'Antiquité, de lire d'abord « Empire » (son meilleur livre) ou « Une journée dans la Rome antique ».

Il y en a des livres, qui parlent d'Internet et, dans le lot, certains parlent de politique. Mais la plupart se limitent aux services visibles (YouTube, TikTok, ce que connait l'auteur) alors que ce livre de Francesca Musiani parle bien de l'Internet : en quoi son infrastructure est-elle politique ?

Ce livre est tiré de son HDR et, donc, si vous avez déjà lu ses autres articles, vous n'aurez pas de révélations radicales. Mais même dans ce cas, il est agréable de pouvoir lire un livre qui, en français, rassemble de manière cohérente et bien intégrée, des années de recherche. L'auteure explique bien la façon dont l'Internet est géré (ou pas géré, justement), et en quoi il est à la fois un outil et un enjeu de pouvoir.

Cinq passionnantes études de cas forment l'essentiel du livre : la « gouvernance de l'Internet » (sujet battu et rebattu, oui, mais ici traité de façon sérieuse), le DNS, Bitcoin, Signal et le cas de la Russie. Même si vous connaissez bien l'Internet, vous apprendrez certainement quelque chose. Et cela vous donnera peut-être envie d'agir pour que le futur de l'Internet soit celui que nous voulons.

Un curieux roman policier suédois mais qui ne ressemble pas aux « polars scandinaves » habituels. D'abord, ça se passe au XIXe siècle, ensuite le héros n'est pas alcoolique (et même tout le contraire).

Le livre est inspiré d'un personnage réel, Lars Levi Læstadius, un pasteur intégriste qui faisait également de la botanique et, mais dans le roman seulement, de l'enquête policière. Dans une partie de la Finlande dominée par la Suède, où règne une stricte hiérarchie des langues (d'abord le suédois, puis le finnois, puis tout en bas le same), dans une région secouée par le mouvement de l'Éveil (ce qui perturbe pas mal l'enquête), le héros doit trouver le coupable d'une série de meurtres que certains attribuent à un ours. Le quatrième de couverture de l'édition français cite évidemment Le nom de la rose, pour le personnage du religieux-enquêteur mais Læstadius est bien plus rigide religieusement que Guillaume.

Croyez-moi, vous allez probablement être accroché rapidement si vous aimez les enquêtes policières. L'enquêteur ne traine pas sa dépression tout au long du livre, au contraire, il a une énergie débordante, qui contraste avec le calme de son assistant.

Le protocole CoAP est un protocole léger, conçu pour les objets connectés. Ce RFC décrit comment faire du DNS au-dessus de CoAP. Si votre brosse à dents a besoin de faire du DNS, c'est ce RFC qu'il faut lire.

CoAP, normalisé dans le RFC 7252, ressemble à HTTP mais en plus simple. Il vise le marché des objets contraints (en mémoire, énergie, en capacité réseau, en puissance de calcul…, voir le RFC 7228). CoAP permet à un client d'envoyer des requêtes à un serveur, et notre tout neuf RFC 9953 explique comment utiliser CoAP pour faire des requêtes DNS et recevoir des réponses DNS. Comme CoAP peut être vu, de manière simplifiée, comme une variante légère de HTTP, ce DNS sur CoAP, alias DoC (DNS over CoAP), est très proche dans ses principes de DoH (RFC 8484). Les contraintes de l'Internet des objets empêchent votre tournevis ou votre ampoule électrique de faire du DoH (qui implique HTTPS), d'où ce DoC. Bien sûr, il y avait toujours la possibilité de faire du DNS sur DTLS, comme le décrit le RFC 8094, mais CoAP a plein de fonctions sympas pour les objets contraints (transferts par blocs - RFC 7959, qui résout les problèmes de MTU, relais CoAP, etc).

L'architecture générale de DoC est très proche de celle de DoH : le client DoC interroge un serveur DoC qui est lui-même un client DNS, parlant typiquement à un résolveur DNS. La communication entre le client DoC et le serveur DoC utilise CoAP, celle entre le serveur DoC et le résolveur utilise le DNS normal, sur UDP, TCP, TLS, etc.

Le serveur DoC sera a priori désigné par le chemin /. Le but est que les messages soient plus courts (DoH utilise souvent le chemin /dns-query). Au fait, comment le client DoC trouve-t-il le serveur (section 3 du RFC) ? Plusieurs méthodes sont admises, de la configuration manuelle (« le serveur DoC est en coaps://doc.foobar.example/ ») aux répertoires CORE (RFC 9176) en passant par les classiques DHCP ou RA ou bien par la découverte de résolveurs du RFC 9462. Ces différentes solutions sont plus ou moins sûres, et plus ou moins pratiques pour l'administrateur/utilisateur (et en général les plus pratiques sont les moins sûres).

Mais ce n'est pas tout : le serveur DoC peut aussi être trouvé via le DNS, avec un enregistrement SVCB (RFC 9460 et RFC 9461), si l'objet contraint a déjà un moyen d'interroger le DNS (la clé SVCB est docpath, numéro 10).

Une fois qu'on connait le serveur, on peut lui parler. La section 4 décrit les messages CoAP échangés. Ils sont étiquetés avec le type application/dns-message (valeur numérique 553).

La méthode CoAP utilisée est FETCH (RFC 8132), qui n'a pas d'équivalent HTTP, contrairement à la plupart des méthodes CoAP. DoC utilise le principe REST (RFC 6690). Le RFC recommande de ne pas oublier le champ Accept: pour indiquer le type de données accepté. Le type recommandé est application/dns-message. Dans la requête, le Query ID DNS devrait être à 0, CoAP se charge de mettre en correspondance requêtes et réponses donc cet identificateur n'est pas utile (c'est pareil pour DoH).

Et les réponses ? Là encore, comme pour DoH, les codes de retour CoAP indiquent si le serveur DoC a pu être joint et a pu faire son travail, pas si la requête DNS a eu une réponse satisfaisante. Autrement dit, tant que le serveur DoC fonctionne bien, il renvoie le code 2.05 (RFC 7252, section 5.9.1.5.) et c'est dans le message DNS qu'on saura si la résolution DNS a renvoyé NOERROR, SERVFAIL, NXDOMAIN, etc.

La mémorisation des réponses joue un rôle plus grand en CoAP qu'en HTTP (rappelez-vous que CoAP sert à des objets contraints). Le RFC demande donc que les TTL dans la réponse DNS soient constants, afin que l'ETag (RFC 7252, section 5.10.6), s'il est calculé via un condensat, ne change pas. Le serveur DoC doit par contre mettre un champ Max-Age: dans sa réponse (section 4.3.2).

Voici, tiré du RFC, un exemple de réponse CoAP, formaté en texte :

2.05 Content
Content-Format: 553 (application/dns-message)
Max-Age: 58719
Payload (human-readable):
    ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
    ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;example.org.                 IN      AAAA
    ;; ANSWER SECTION:
    ;example.org.         79689   IN      AAAA    2001:db8:1:0:1:2:3:4

  

Et la sécurité ? Le RFC recommande de sécuriser la communication avec le système OSCORE du RFC 8613 (ou, sinon, le DTLS du RFC 9147, ce qui donne du CoAPS). Le RFC note que cela assure la sécurité de la communication entre le client DoC et le serveur DoC mais que, après, on ne sait pas ce que fait le serveur (la section 8 recommande évidemment que le serveur DoC valide avec DNSSEC).

Questions mises en œuvre de DoC, on trouve (mais je ne les ai pas testées, je ne fais pas d'Internet des Objets), par les auteurs du RFC, dans RIOT, un client en C (source sur Github) et un serveur en Python.

Si vous voulez allez plus loin que ce résumé sommaire, une bonne lecture est le papier de 2023 des auteurs, « Securing Name Resolution in the IoT: DNS over CoAP ».

Ce RFC spécifie comment mettre des clés ML-KEM dans un certificat X.509. Vous allez me dire « Mais ML-KEM est un algorithme d'échange de clés, pas de signature, que fait-il dans un certificat ? » Et je vous répondrai que vous avez raison, d'ailleurs le RFC restreint sérieusement ce qu'on peut faire avec cet algorithme.

ML-KEM a l'intéressante propriété d'être résistant aux calculateurs quantiques. Il est normalisé dans FIPS 203. Ce RFC permet de l'utiliser dans les certificats normalisés dans le RFC 5280, et il décrit trois variantes, ML-KEM-512, ML-KEM-768 et ML-KEM-1024.

Comme indiqué plus haut, autant il était normal de permettre ML-DSA dans les certificats (RFC 9881), autant cela peut sembler surprenant pour ML-KEM. La section 1.1 de notre RFC explique les usages (limités) d'un algorithme d'échange de clés dans un certificat. C'est par exemple utile pour un protocole où vous avez besoin d'une clé publique, que vous allez tirer du certificat. Mais vous ne pourrez pas utiliser les certificats de ce RFC pour faire du TLS sur l'Internet public, aucune AC ne vous en produira, même si TLS le permet un jour. Pour la même raison, vous n'en trouverez pas dans les journaux Certificate Transparency.

Les trois algorithmes sont identifiés en suivant le RFC 5912, par un OID via le NIST ; Ce sont id-alg-ml-kem-512 (2.16.840.1.101.3.4.4.1), id-alg-ml-kem-768 (2.16.840.1.101.3.4.4.2) et id-alg-ml-kem-1024 (2.16.840.1.101.3.4.4.3).

La section 5 du RFC précise que les bits indiquant les utilisations possibles de ces certificats (RFC 5280, section 4.2.1.3) doivent indiquer uniquement le chiffrement d'une clé (et pas l'authentification, comme avec les certificats habituels).

Le module ASN.1 figure dans l'annexe A, si vous voulez implémenter ce RFC (il faut aussi importer les modules des RFC 5912 et RFC 9629). Le module est identifié par id-mod-x509-ml-kem-2025 et a l'OID 1.3.6.1.5.5.7.0.121. Le gros du RFC est constitué d'exemples de clés et de certificats ML-KEM (annexe C), dans l'encodage en texte du RFC 7468.

Allez, un peu de pratique avec OpenSSL 3.5 :

% openssl genpkey -algorithm ML-KEM-512 -out ml-kem-key.pem -outform PEM

% cat ml-kem-key.pem
-----BEGIN PRIVATE KEY-----
MIIGvgIBADALBglghkgBZQMEBAEEggaqMIIGpgRAOwWCnP71SklfOIuwiLrIddsm
Up4AlOMwvwjqCy4PHr8fSq5jRjFoP6XYXnl8IQCR9HhzSRVffI09hBezOUrmxgSC
…

# Analysons cette clé :
% openssl pkey -text -in ml-kem-key.pem 

# Demandons une signature du certificat :
% openssl req -new -key ml-kem-key.pem  -provider default -out req.csr 
…
40E7CEC0027F0000:error:03000096:digital envelope routines:do_sigver_init:operation not supported for this keytype:../crypto/evp/m_sigver.c:305:

Ah, là, c'est raté, et c'est logique. OpenSSL n'accepte pas de fabriquer un CSR pour ces clés « operation not supported for this keytype » puisque ML-KEM ne permet pas de signer. La solution :

# Extraire la clé publique :
% openssl pkey -in ml-kem-key.pem -pubout   -out mlkem.pub

# Fabriquer une clé ECDSA pour signer :
% openssl ecparam -out ec_key.pem -name secp256r1 -genkey 

# Signer :
% openssl x509 -new \
  -subj "/CN=test-mlkem" \
  -force_pubkey mlkem.pub \
  -signkey ec_key.pem \
  -days 365 \
    -out mlkem-cert.pem
Warning: Signature key and public key of cert do not match

L'avertissement est normal, puisqu'on a effectivement utilisé une autre clé, d'un autre algorithme, pour signer le certificat contenant notre clé publique ML-KEM. Mais tout s'est bien passé :

% openssl x509 -text -in mlkem-cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            69:33:f9:1e:e5:34:64:84:d9:f4:b2:15:3b:50:ec:36:db:0b:71:5c
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=test-mlkem
        Validity
            Not Before: Feb 16 15:30:02 2026 GMT
            Not After : Feb 16 15:30:02 2027 GMT
        Subject: CN=test-mlkem
        Subject Public Key Info:
            Public Key Algorithm: ML-KEM-512
                ML-KEM-512 Public-Key:
                ek:
                    d8:d2:6c:c4:9b:96:48:23:0d:ce:f7:0d:b3:0b:85:
                    …
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                E7:B2:03:92:37:EC:C6:35:E4:F0:2E:AC:4E:1C:F2:81:67:F7:95:29
            X509v3 Authority Key Identifier: 
                15:E5:2A:5E:B1:C3:50:69:7E:E4:48:EA:0F:DD:3C:5C:90:4B:7C:CC
    Signature Algorithm: ecdsa-with-SHA256
  

La technique ECH (Encrypted Client Hello) permet de boucher une faille de TLS, la transmission en clair du nom du serveur demandé. Elle est normalisée dans le RFC 9849 mais il y manquait la description d'un format standard pour envoyer les données nécessaires à ECH. C'est désormais fait (et vous reconnaitrez le classique format PEM, cf. RFC 7468).

Le principe d'ECH est de chiffrer le nom du serveur demandé, avec la clé publique du serveur TLS. Pour configurer le serveur, il faut la clé privée correspondante et différents détails, la ECHConfig (RFC 9849, section 4). C'est pour ECHConfig que notre RFC normalise un format.

Le fichier PEM (RFC 7468) contient une ou plusieurs clés privées et des informations de configuration (pour un ou plusieurs serveurs), le tout en Base64 (section 4 du RFC 4648). Les informations publiques sont typiquement mises dans le DNS (RFC 9848), la clé privée, cela va sans dire (mais le RFC le dit quand même, on ne sait jamais) n'est pas publiée. Un fichier PEM contenant des clés privées doit évidemment être bien protégé.

Voici un exemple, tiré du RFC (la clé privée a donc déjà été publiée 😁) :

   -----BEGIN PRIVATE KEY-----
   MC4CAQAwBQYDK2VuBCIEICjd4yGRdsoP9gU7YT7My8DHx1Tjme8GYDXrOMCi8v1V
   -----END PRIVATE KEY-----
   -----BEGIN ECHCONFIG-----
   AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRCwAEAAEA
   AQALZXhhbXBsZS5jb20AAA==
   -----END ECHCONFIG-----
  

Dans le DNS, la publication de la clé publique et de la configuration donnerait quelque chose du genre :

% dig +short HTTPS foo.example.com
1 . ech=AD7+DQA65wAgACA8wVN2BtscOl3vQheUzHeIkVmKIiydUhDCliA4iyQRwAEAAEAAQALZXhhbXBsZS5jb20AAA==    
  

Bien des logiciels reconnaissent cette syntaxe. Je ne les ai pas testés mais, apparemment :

• Dans une branche d'OpenSSL (les tests sont dans test/ech_test.c, avec des exemples du format de ce RFC. Apache ou HAProxy peuvent l'utiliser.
• Pour BoringSSL, il y a ce script.

La cryptographie est indispensable à la sécurité dans l'Internet d'aujourd'hui. Mais sa mise en œuvre peut être délicate, par exemple lorsqu'il y a un problème d'œuf et de poule : quand un client TLS se connecte, il envoie en clair au serveur le nom de domaine utilisé, le serveur ayant besoin de cette information pour choisir le bon certificat qui servira pour choisir les paramètres de chiffrement qui protégeront le reste de la session. Cet envoi en clair pose un problème de vie privée, et est parfois utilisé pour la censure, par exemple en Russie. Il faut donc chiffrer ce nom annoncé, ce SNI. Mais avec quelle clé, puisqu'on a besoin du nom pour avoir une clé ? Ce RFC fournit un mécanisme pour cela, ECH (Encrypted Client Hello), qu'on pourrait traduire par « salutation chiffrée ».

Pour voir une communication TLS classique, avant ECH, vous pouvez regarder un pcap, sni.pcap. Le quatrième paquet contient le Client Hello, avec (vu par Wireshark) :

Extension: server_name (len=20) name=www.langtag.net

Le nom demandé est donc en clair. Pas bien. C'est ainsi qu'en Russie, le système TSPU (ТСПУ, технические средства противодействия угрозам, mesures techniques de protection) détecte les noms censurés dans le SNI et envoie un faux paquet TCP RST (ReSeT). C'est mis en œuvre, par exemple, dans les boitiers SORM.

Un petit avertissement tout de suite : on lit assez souvent que la version 1.3 de TLS (normalisée dans le RFC 8446) chiffre ce SNI. C'est faux et, si vous lisez cela dans un article, vous saurez que l'auteur ne vérifie pas ce qu'il raconte. TLS 1.3 chiffre davantage de choses que les versions précédentes, mais pas le SNI.

C'est que chiffrer le SNI, ou, encore mieux, tout le Client Hello, est compliqué puisque le client doit obtenir une clé publique du serveur, avant d'avoir pu lui indiquer le nom de domaine souhaité. Il faut donc au client une autre clé publique que celle du certificat. Notez qu'il n'y a pas que le SNI qui est sensible, l'ALPN (RFC 7301) l'est aussi, et c'est pour cela que le choix de notre RFC est de chiffrer tout le message Client Hello. Toujours côté analyse de la menace, notez qu'ECH n'est utile que si le même serveur TLS gère plusieurs domaines. S'il n'en a qu'un, un observateur saura lequel, juste par l'adresse IP du serveur. ECH vise à empêcher cet observateur de savoir quel domaine était choisi, au sein d'un anonymity set, l'ensemble des domaines hébergés sur ce serveur.

Le RFC est long mais le principe d'ECH est simple. (Au fait, le cahier des charges d'ECH est dans le RFC 8744.) La section 3 le résume. ECH a deux modes, shared et split mais qui fonctionnent de manière très proche. Pour les configurations simples (le serveur est composé d'une seule machine), shared suffit. Pour les cas où le « serveur » est en fait composé de deux machines, une frontale (qui relaie le TLS sans l'interpréter) et une dorsale, le split est utilisé. Oubliez cela tout de suite, si c'est important pour vous, voyez la section 10 du RFC pour les détails (et rappelez-vous d'un point de terminologie TLS : « terminer » une session TLS, ce n'est pas y mettre fin, c'est juste être l'extrémité de la session).

On l'a dit, toute la difficulté d'ECH est que le serveur doit publier une clé qui permettra le chiffrement du ClientHello. Notre RFC n'impose pas une manière unique de la publier. Elle peut être manuellement et statiquement configurée chez le client, par exemple. Mais la méthode qui sera sans doute la plus courante est une publication dans le DNS, via les enregistrements SVCB (RFC 9848). (En fait, le serveur va publier une clé et des métadonnées associées.) Une fois muni de cette clé, le client chiffre son Client Hello et met le message chiffré (ClientHelloInner, dit le RFC) dans une extension du Client Hello normal (appelé ClientHelloOuter dans le RFC), extension nommée encrypted_client_hello (enregistrée avec le numéro 65037). Le serveur va déchiffrer l'extension, récupérant le bon nom de domaine, et continuera ensuite comme d'habitude.

Notez que le client doit bien mettre un nom de domaine dans le SNI du ClientHelloOuter (envoyé en clair). La section 6.1 du RFC détaille ce qu'il faut placer dans cette « salutation chiffrée ».

Et voici le pcap produit : ech.pcap. Le client annonce un nom cover.defo.ie dans le SNI mais le vrai nom (defo.ie) est dans l'extension ECH (et vous ne le voyez pas, bien sûr, il est chiffré) :

Extension: encrypted_client_hello (len=473)
    Type: encrypted_client_hello (65037)
    Length: 473
    Client Hello type: Outer Client Hello (0)
    Cipher Suite: HKDF-SHA256/AES-128-GCM
    Config Id: 185
    Enc length: 32
    Enc: 6acfeceeea540b510bad0b28f5a9913af4e52cbdc1496750d91658d1e2200a3e
    Payload length: 431
    Payload [truncated]: b8f50aa3492607d8c05c1150b4f12496cf3910468ed82e775c0c0d64…
  

Et un exemple de requête DNS pour récupérer la clé ECH :

% dig  tls-ech.dev HTTPS

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> tls-ech.dev HTTPS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33050
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1472
;; QUESTION SECTION:
;tls-ech.dev.		IN HTTPS

;; ANSWER SECTION:
tls-ech.dev.		60 IN HTTPS 1 . ech=AEn+DQBFKwAgACABWIHUGj4u+PIggYXcR5JF0gYk3dCRioBW8uJq9H4mKAAIAAEAAQABAANAEnB1YmxpYy50bHMtZWNoLmRldgAA

;; Query time: 132 msec
;; SERVER: 192.168.0.254#53(192.168.0.254) (UDP)
;; WHEN: Mon Apr 15 18:46:04 CEST 2024
;; MSG SIZE  rcvd: 134

(Pour Cloudflare, regardez cloudflare-ech.com, le nom choisi par cette entreprise pour ECH.)

À ce stade, vous savez l'essentiel. Lisez le RFC si vous voulez les détails de syntaxe (sections 5 à 7). Voyons plutôt le problème de déploiement pratique dans l'Internet (section 8 du RFC). ECH nécessite de changer clients et serveurs et nous pouvons être sûrs qu'il y aura une longue période de coexistence de logiciels ECH et non-ECH. On verra sans doute aussi des cafouillages comme un serveur qui publie une clé pour ECH mais ne gère pas ECH (le RFC prévoit un mécanisme de détection de ce problème et de ré-essai - section 6.1.6 - dans ce cas, si bien que le serveur qui ferait cette erreur imposera un délai de connexion plus long à ses clients).

Pour éviter que l'utilisation de ECH se remarque trop, le RFC spécifie également (section 2) comment graisser (RFC 9170) les communications TLS afin de rendre plus difficile la détection des vrais usages.

Ah, et le RFC précise, avec un humour discret, qu'ECH va casser « certains usages », euphémisme pour désigner la surveillance mais aussi la censure, que le SNI en clair permettait (pour la censure, on fait du DPI et, si on trouve un nom censuré dans un SNI, on envoie un message TCP RST - ReSeT - mensonger au client). Cela a déjà fait l'objet de critiques, regrettant qu'on ne puisse plus espionner autant.

Cette technique de censure (DPI puis envoi d'un RST TCP si on trouve un nom censuré) est rare en Europe mais très répandue en Russie, notamment depuis le début de la guerre. ECH permet de l'empêcher.

Le but d'ECH est d'améliorer la sécurité de TLS, il n'est donc pas étonnant que la section d'analyse de sécurité, la section 10, soit très détaillée. Elle commence par expliquer le modèle de menace (un attaquant situé sur le trajet, qui peut être actif, capable d'injecter des paquets). ECH empêchera cet attaquant de savoir quel service était demandé, parmi tous ceux hébergés à cette adresse IP (et cela a été formellement prouvé dans « A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello »). Mais il reste des pièges.

ECH peut récupérer la clé du serveur dans le DNS (c'est en tout cas la méthode par défaut) mais n'impose pas DNSSEC donc un attaquant qui peut injecter de faux enregistrements DNS peut casser ECH. La solution est évidemment d'utiliser DNSSEC. (Le RFC note aussi que, si l'attaquant est sur le réseau local de la victime, utiliser DoT ou DoH pour la résolution de noms va aider.)

Certaines extensions de TLS peuvent défaire ECH, par exemple la cached_info du RFC 7924. Elles ne doivent pas être utilisées dans le ClientHelloOuter. ALPN peut aussi être révélateur si un client envoie des ALPN différents à différents serveurs. Là encore, ne pas le mettre dans le ClientHelloOuter.

La vérification du certificat contient également des risques, si on utilise OCSP, dont la requête peut trahir le nom du serveur contacté.

Le RFC note à juste titre qu'un observateur indélicat a d'autres moyens à sa disposition pour découvrir le domaine demandé. Le plus évident est le DNS (cf. RFC 7626), et il faut donc utiliser les mécanismes de protection de la vie privée (RFC 7858, RFC 8484, mais aussi RFC 9156, que le RFC sur ECH a malencontreusement oublié).

Et il y a bien d'autres faiblesses possibles si on utilise mal ECH, lisez la section 10 si vous voulez en savoir plus, vous apprendrez plein de choses.

ECH a été défini il y a déjà plusieurs années. (Le projet ECH à l'IETF a duré bien plus longtemps que prévu. Ce RFC a commencé sa vie en 2018.) Il existe de nombreuses mises en œuvre. On le trouve par exemple dans Firefox (cf. leur documentation « Comprendre le client chiffré Hello (ECH) » ou bien le wiki pour des détails pointus). Les bibliothèques TLS en logiciel libre, comme BoringSSL ou OpenSSL ont souvent ECH (mais pas forcément dans une version officielle et publiée). Si vous voulez tester si votre client TLS gère ECH, il existe plusieurs sites Web pour cela : https://defo.ie/ech-check.php, https://tls-ech.dev/ ou https://www.cloudflare.com/ssl/encrypted-sni/. Côté serveur, c'est en cours, par exemple pour Apache, il y a eu du code, publié à partir de la version 2.5.1 (paramètre SSLECHKeyDir). Et nginx a eu ECH en février 2026. Pour tester vos serveurs, vous pouvez utiliser curl si vous avez un curl récent, compilé avec les bonnes options. Car, sinon (sur un Arch à jour) :

% curl --ech true tls-ech.dev
curl: option --ech: the installed libcurl version does not support this

Pour davantage de tests, il y a echspec :

% echspec www.bortzmeyer.org
TLS Encrypted Client Hello Server
…		HTTPS resource record for www.bortzmeyer.org does NOT have ech SvcParams.
1 failure
  

(Pas d'ECH encore sur ce blog mais ça n'aurait guère d'intérêt puisque peu de sites sont sur ce serveur.)

%  echspec tls-ech.dev       
TLS Encrypted Client Hello Server
…
Failures:

	1) MUST abort with an "illegal_parameter" alert, if ECHClientHello.type is not a valid ECHClientHelloType in ClientHelloOuter. [7-5]
		https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22#section-7-5
		did not send expected alert: illegal_parameter
1 failure

À part un point de détail subtil, tout va bien. Par contre, https://ssllabs.com ne teste pas l'ECH. Dommage.

Quelques lectures intéressantes :

• « Say (an encrypted) hello to a more private internet », une courte explication par Mozilla.
• L'annonce de Cloudflare.
• D'un intérêt historique seulement, la première annonce de Cloudflare, quand ECH s'appelait encore ESNI (car il ne chiffrait que le SNI, pas tout le ClientHello, laissant par exemple l'ALPN sans protection).

Le protocole ECH (Encrypted Client Hello, normalisé dans le RFC 9849) permet de chiffrer la salutation TLS (le ClientHello), notamment le nom du serveur auquel on se connecte. Mais pour cela, il faut la clé publique du serveur. Un des moyens de la récupérer est dans le DNS, comme normalisé dans notre RFC 9848.

C'est qu'ECH pose un problème de cercle vicieux : le serveur TLS (RFC 9846) a besoin du nom demandé par le client pour choisir le bon certificat, donc la bonne clé or, si on veut chiffrer ce nom, il nous faut bien une clé. ECH (RFC 9849) résout le problème en disant que le client TLS va récupérer une clé publique distincte de celle contenue dans le certificat, quelque part. Où ça ? Le RFC 9849 ne le dit pas, mais plusieurs solutions existent, dont notre nouveau RFC qui propose de récupérer cette clé dans le DNS.

Il s'appuie sur les enregistrements SVCB du RFC 9460. Ces enregistrements permettent d'indiquer un grand nombre de paramètres, sous une forme nom=valeur (les « SvcParams »). Les enregistrements HTTPS sont une des formes des SVCB et c'est en général eux qui seront utilisés pour ECH :

    
% dig defo.ie HTTPS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44251
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
defo.ie.		1750	IN	HTTPS	1 . ipv4hint=213.108.108.101 ech=AMD+DQA8ngAgACCBNprc0M4mwJt8Z+q6DtisBc3nQQUwLcEvepAUv27sLQAEAAEAAQANY292ZXIuZGVmby5pZQAA/g0APJsAIAAg4dzhbvv/9BNikgK3mrvQwKGdWhTiXwd9jpkNhgJ2rgkABAABAAEADWNvdmVyLmRlZm8uaWUAAP4NADzTACAAIEwBExilsbqu9AdG7lutdyZQrIm6Lo4fErwINXCylJNDAAQAAQABAA1jb3Zlci5kZWZvLmllAAA= ipv6hint=2a00:c6c0:0:116:5::10
…

  

Que voit-on ? Que defo.ie a bien un enregistrement de type HTTPS (dont je rappelle qu'il est une spécialisation du SVCB), qui contient un paramètre ECH (la clé publique et quelques autres informations, mais je ne connais pas de moyen simple d'afficher ces informations).

La section 3 est l'essentiel du RFC. Elle définit le paramètre (« SvcParam ») ech, dont la valeur est la clé publique ECH du serveur TLS. Plus précisément, sa valeur est une « ECHConfigList », concept créé par le RFC 9849 (cf. sa section 4), et qui décrit tous les paramètres utiles pour faire de l'ECH. Ce paramètre a été ajouté au registre IANA des SvcParams (section 9 de notre RFC).

Si vous voulez fabriquer vous-même un tel enregistrement, la documentation d'Apache donne des explications (mais il faudra des versions très récentes des logiciels et probablement compilées par vous-même avec les bonnes options).

La section 4 du RFC décrit les conditions d'un déploiement efficace, côté serveur. Si on publie un enregistrement SVCB incluant du ech, il faut évidemment s'assurer que le serveur TLS gère ECH. (Un exemple d'outil qui fait ce genre de vérification est echspec.) La section 5 du RFC fait la même chose, mais côté client ; elle discute notamment des questions de latence puisqu'un client TLS ne peut pas paralléliser la récupération de l'enregistrement DNS avec l'établissement de la session TLS, celle-ci dépendant de ce qu'on trouvera dans l'enregistrement SVCB.

Il existe un autre moyen d'influencer la session TLS, c'est le champ HTTP Alt-Svc: du RFC 7838. Comme le note la section 6, Alt-Svc: ne peut pas actuellement indiquer de paramètres ECH donc pas de risque de contradiction entre les deux moyens d'obtenir des paramètres TLS sur ce point. En revanche, le serveur doit veiller à ce qu'il publie des enregistrements SVCB avec ECH pour tous les noms qui seraient mentionnés dans le Alt-Svc:.

Et puis, bien sûr (section 8), rappelez-vous que ECH servant à dissimuler le nom du serveur demandé, il ne servirait plus à grand'chose si la requête DNS pour ce nom (et le type HTTPS ou SVCB) était en clair et/ou envoyée à des serveurs qui ne sont pas dignes de confiance. Le RFC recommande donc des connexions DNS chiffrées et authentifiées, avec un résolveur de confiance.

Comme toute organisation humaine, l'IETF doit gérer le cas de personnes pénibles, qui font perdre du temps à tout le monde, mettent une mauvaise ambiance ou cherchent activement à perturber le travail commun. Ce RFC (qui remplace les RFC 3683 et RFC 3934) établit la politique de l'IETF vis-à-vis de ces gens : être patient mais pas trop.

Les principes de base de la gestion des abusifs sont les principes de l'IETF (RFC 3935 et RFC 7154). Il ne s'agit pas d'empêcher les désaccords (ils sont attendus et sains). L'IETF est une organisation très ouverte et ses participant·es sont divers·es. On recherche un consensus approximatif (RFC 7282) mais, bien sûr, s'opposer au consensus n'est pas en soi un problème. L'IETF n'est pas une religion. Mais certains vont « sortir des clous ». L'annexe B du RFC donne quelques exemples (messages hors-sujet sur un groupe, ton agressif, remise en cause permanente des décisions et une pratique que je ne connaissais pas, le sealioning). L'IETF devra réagir, en suivant ces lignes directrices :

• Avoir une politique qui soit cohérente et équitable. Elle doit s'appliquer uniquement sur la base du comportement de la personne et pas, par exemple, selon le nombre de RFC qu'elle a écrit, ni selon son ancienneté.
• Permettre des appels contre les décisions prises (le contrôle est une activité délicate et les décisions seront parfois difficiles).
• Essayer de respecter la vie privée tout en maintenant une certaine transparence (exemple de problème : les sanctions doivent-elles être publiques ?).
• Être flexible car il faudra pouvoir s'appliquer à des cas variés. (Notez la tension entre cet objectif et le premier cité…)

Le travail de contrôle reposera essentiellement sur l'équipe de contrôle (moderation team), décrite en section 2. Elle comportera au moins cinq personnes, nommées par l'IESG, qui devra essayer de respecter une certaine diversité. Ces personnes ne doivent pas être membres de l'IESG ou de l'IAB. La diversité souhaitée inclut celle des fuseaux horaires car l'équipe devra parfois réagir vite. L'IETF LLC, la structure administrative décrite dans le RFC 8711, se chargera de leur financer une formation.

Leur travail couvrira toutes les discussions publiques en ligne à l'IETF, qu'elles soient sur une liste de diffusion, un dépôt GitHub, etc. Le RFC distingue les administrateurs, qui gèrent un de ces lieux de discussion, de l'équipe de contrôle. Les administrateurs signalent les problèmes et appliquent les décisions de l'équipe de contrôle. Mais, évidemment, pour éviter de surcharger cette équipe, les administrateurs sont aussi censés gérer la plupart des problèmes localement. L'idée derrière l'équipe centrale (moderators) est d'avoir un groupe formé et qui pourra s'assurer d'une politique cohérente au niveau de l'IETF. Vu la taille de l'IETF, les contrôleurs ne pourront pas tout surveiller préventivement et dépendront donc beaucoup des signalements faits, par exemple par les administrateurs.

Vous ne l'avez peut-être pas noté plus haut mais le mot important est « publiques ». L'équipe de contrôle ne va pas gérer les communications privées. Par ailleurs, elle contrôle des comportements, pas le contenu (donc, pas la peine de lui demander de censurer telle ou telle partie d'un Internet-Draft). Quand au spam, il est effectivement un exemple de comportement perturbateur mais il y a déjà une politique à ce sujet.

Ce sera à l'équipe de contrôle de définir ses processus de fonctionnement et ses détails de politique, pour ce qui n'est pas déjà couvert dans ce RFC 9945. Tout cela devra évidemment être discuté au sein de l'IETF et, au bout du compte, approuvé par l'IESG et rendu public (mais pas forcément dans un RFC).

Qu'est-ce que pourra faire en pratique l'équipe de contrôle ? Le RFC donne quelques exemples (section 4) :

• Faire passer les messages d'une personne par un système d'approbation explicite (par défaut, l'IETF n'a pas de contrôle a priori),
• Engueuler quelqu'un, en privé ou en public,
• Supprimer complètement le droit d'écriture à une personne.

Et l'équipe de contrôle devra évidemment garder trace de ces actions, pour en rendre compte. Et des appels sont possibles (RFC 2026, sections 6.5.1 et 6.5.4).

Il y a d'autres fonctions dans l'IETF qui ont un rapport avec cette nécessité de contrôler les débordements de certains participants (section 5). C'est le cas de l'ombudsteam et de l'incarnation administrative de l'IETF, la LLC (notamment si le comportement de certains entraine des risques juridiques pour l'IETF). Il y a aussi plein d'autres RFC à lire, comme le RFC 7776, sur les mesures contre le harcèlement ou le RFC 9245, sur la gestion des listes de diffusion (rappelez-vous que l'équipe de contrôle ne sera pas limitée à ces listes).

Le RFC remarque à juste titre (section 6) que toute politique peut être utilisée de manière abusive, par exemple à des fins de censure. La section 6 revient sur les différentes décisions décrites par le RFC et comment elles contribuent à minimiser ce risque.

Notez que ce RFC s'applique à l'IETF uniquement, et pas aux autres organisations proches comme l'IRTF.

Enfin, l'annexe A explique les motivations derrière ce RFC et le pourquoi des différents choix. Malgré la quantité de RFC et de décisions documentées, il n'était pas toujours évident de reconnaitre ce qui était un comportement perturbateur. Et les processus existants étaient trop lents, en partie parce qu'ils supposaient que tout le monde était de bonne foi. D'où ce nouveau RFC qui explique comment un meilleur mécanisme va être défini.

L'algorithme de condensation FNV, présenté dans ce RFC n'est pas neuf (et certains disent même qu'il est dépassé). Mais il est utilisé par de nombreux logiciels alors qu'il n'avait jamais été spécifié « proprement ». Voilà qui est fait.

FNV a comme principal avantage ses performances : il est rapide et le code est court. Comme le précise le titre du RFC, il n'a pas les caractéristiques des algorithmes de condensation utilisés pour des services de sécurité. Mais cela ne l'empêche pas d'être déployé depuis de nombreuses années pour bien d'autres usages.

Le RFC fait 137 pages mais ne vous affolez pas, FNV est simple et l'essentiel de ces pages est composé de code mettant en œuvre FNV de diverses manières. J'emprunte au RFC, section 2 (avec les modifications de l'article de Wikipédia pour que ce soit plus clair) l'essentiel de l'algorithme, en pseudo-code :

algorithm fnv-1 is
    hash := FNV_offset_basis

    for each byte_of_data to be hashed do
        hash := hash × FNV_prime
        hash := hash XOR byte_of_data

    return hash 
  

C'est court et rapide, non ? Mais, et le RFC le rappelle plusieurs fois (car des critiques sérieuses du projet de RFC avait insisté sur cette question) : cet algorithme ne doit pas être utilisé pour le cas où on veut de la résistance aux attaques comme la pré-image (section 1.1 du RFC). Ainsi, Python utilisait FNV mais a arrêté.

Qu'est-ce qui fait que FNV se retrouve qualifié de « non-cryptographique » et pas utilisable pour la sécurité ? La section 1.3 liste les limites de FNV (voir aussi la section 6) comme le fait que chaque bit du condensat ne dépend pas de tous les bits de la donnée d'entrée ou comme le fait que FNV est trop rapide. Oui, pour la sécurité, cela peut être un problème : si on utilise une fonction pour condenser des mots de passe, on ne veut pas faciliter la tâche de l'attaquant qui va chercher un mot de passe ayant ce condensat, en essayant beaucoup de mots de passe possibles. Une fonction de condensation a donc intérêt à être lente, comme Argon 2 (RFC 9106).

Vous trouverez par contre du FNV un peu partout (la section 1.2 vous donne une liste), dès que ces questions de sécurité ne sont pas pertinentes. FNV est même cité dans des RFC, le RFC 7357 ou le RFC 7873 (les cookies du DNS) ou bien dans la norme IEEE 802.1Qbp.

FNV a une longue histoire (section 7 du RFC), ayant commencé en 1991. On notera que la définition de FNV inclut quelques valeurs largement arbitraires comme, par exemple, la chaine de caractères « chongo <Landon Curt Noll> /\../\ », dont le condensat fournit le paramètre offset_basis (section 2.2). Cette chaine était dans le .signature d'un des auteurs de FNV mais, c'est amusant, avait été mal recopiée.

Le gros (en nombre de pages) du RFC étant constitué de code source en C, avec des variantes selon le nombre de bits produits, plutôt que de tenter de l'extraire du RFC, utilisons cette archive tar que j'ai constituée :

% tar xzvf FNV-RFC.tar.gz

% cd FNV-RFC

% echo -n toto > tmp  

% make FNVhash

% ./FNVhash -t 64 -f tmp 
FNV-64 test of return values passed.  
FNV-64 Hash of contents of file 'tmp': ADC7B038EFF1F42F 

Et voilà, FNV marche. Il existe d'autres mises en œuvre. Celle de référence est présentée ici et est également sur Github :

 
% git  clone https://github.com/lcn2/fnv

% cd fnv 

% make

% ./fnv1a64 -s toto
0x2ff4f1ef38b0c7ad

[Oui, les octets ne sont pas affichés dans le même ordre qu'avec le code du RFC.]  

Vous avez aussi d'autres mises en œuvre (une des plus rigolotes est en Fortran). Et elle n'est pas listée mais il y a une mise en œuvre de FNV dans le langage Zig (notez son utilisation de comptime).

Et pour finir, si vous vous demandez quelle fonction de condensation utiliser, il y a une comparaison de FNV avec SHA-1 (RFC 3174) et SHA-256 (RFC 6234) dans l'annexe A.

Un certificat est signé par une AC, normalement, ou à la rigueur auto-signé, ce qui ne sert pas à grand'chose mais est obligatoire dans X.509. Mais voici que ce RFC rend la signature facultative.

À ma connaissance, le seul intérêt d'auto-signer son certificat est de prouver qu'on a bien la clé privée correspondante (car un plaisantin peut toujours fabriquer un certificat avec la clé publique de quelqu'un d'autre) et, en prime, de vérifier l'intégrité. C'est pas crucial. Mais la norme X.509 (cf. RFC 5280) ne permet pas d'avoir un certificat sans signature. Notre RFC 9925 contourne cette obligation en enregistrant un nouvel algorithme, id-alg-unsigned, qui indique qu'il n'y a pas de signature du tout.

C'est parce que, parfois, on n'a pas besoin des signatures. Un exemple typique se trouve dans votre magasin d'AC : vous ne vérifiez pas les signatures (vous ne pouvez pas, puisque les AC sont à la racine de la validation, RFC 5280, section 6), la seule présence du certificat dans le magasin inspire la confiance. Les certificats des AC sont donc auto-signés, ce qui ne sert pas à grand'chose, à part à satisfaire les exigences syntaxiques du format X.509. Ici, le certificat d'une AC du magasin de ma machine Ubuntu ; Issuer est égal à Subject, le certificat est auto-signé :

% openssl x509 -text -in /etc/ssl/certs/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
Certificate:
        Issuer: C = ES, CN = Autoridad de Certificacion Firmaprofesional CIF A62634068
        Subject: C = ES, CN = Autoridad de Certificacion Firmaprofesional CIF A62634068
	…
           X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
        …	

(Une autre solution serait le RFC 5914 mais il ne semble pas très courant.)

Un autre cas où on se moque de la signature du certificat est celui où le certificat est validé d'une autre façon, par exemple un serveur EPP sur TLS qui a une liste de tous les clients possibles, et des certificats que le registre a distribués à ses BE.

Donc, il y a des cas où la signature ne sert guère, voire pas du tout. Mais est-ce gênant ? Ce n'est pas dramatique mais, dans certains cas, c'est sous-optimal, par exemple :

• Les signatures post-quantiques sont souvent de grande taille, donc cela rend les certificats plus gros pour rien.
• La clé publique dans le certificat peut utiliser un algorithme qui ne permet pas la signature (comme ML-KEM, cf. le futur RFC draft-ietf-lamps-kyber-certificates).

La section 3 du RFC fournit les détails techniques. Dans le certificat, on met le champ signatureAlgorithm à id-alg-unsigned et le champ signatureValue à une chaine vide. Le champ issuer pourrait être vide puisque personne n'a signé le certificat, mais comme il était obligatoire, pour éviter de choquer les applications actuelles, il vaut mieux mettre un issuer égal au subject (comme pour un auto-signé). On a le droit de mettre plutôt un nom /id-rdna-unsigned= (en fait 1.3.6.1.5.5.7.25.1 mais je montre la représentation textuelle du RFC 4514). RDNA signifie Relative Distinguished Name Attribute et un nouveau registre, « SMI Security for PKIX Relative Distinguished Name Attribute », est créé pour accueillir id-rdna-unsigned et d'autres futurs noms (politique de Spécification nécessaire, cf. RFC 8126).

Quand une application rencontre un de ces certificats non signés, si elle valide les signatures, elle doit évidemment rejeter le certificat. Si elle est plus laxiste (ou bien a d'autres mécanismes de vérification), elle peut l'accepter (section 4). Les applications et bibliothèques existantes font déjà cela (elles rejettent les signatures d'algorithmes inconnus) donc l'introduction des certificats non signés ne devrait rien casser.

Quelques conseils de sécurité figurent en section 5, par exemple de ne pas réutiliser les clés dans des contextes différents. (X.509, jusqu'à présent, ignorait ce conseil pour les certificats auto-signés puisque la clé publiée servait aussi à signer. Plus de signature, plus de problème.)

Désolé, mais je n'ai pas trouvé comment générer aujourd'hui de tels certificats, que ce soit avec OpenSSL (c'est en cours) ou d'autres logiciels. Si vous trouvez, ça m'intéresse, je pourrais mettre des essais pratiques ici.

Vous reprendrez bien un peu de post-quantique ? Ce RFC normalise l'utilisation de signatures ML-DSA dans les certificats X.509.

ML-DSA est un des premiers gagnants du concours du NIST (il se nommait Dilithium à l'époque). Il est normalisé dans FIPS-204. Il utilise les réseaux euclidiens. C'est un algorithme de signature et il a donc toute sa place dans les certificats X.509, aux côtés des plus classiques RSA et ECDSA. Petit rappel de cryptographie post-quantique au passage : contrairement à RSA, ML-DSA ne sait faire que les signatures, pas l'échange de clés. Vous pouvez donc mettre des clés publiques ML-DSA dans un certificat, le signer avec ML-DSA mais, pour un protocole comme TLS, il faudra utiliser autre chose pour l'échange de clés (par exemple ML-KEM, autre vainqueur du concours NIST).

Mettre du post-quantique dans les certificats était moins urgent que dans l'échange de clés : ici, pas de risque qu'un attaquant prévoyant stocke des communications chiffrées, en attendant d'avoir un calculateur quantique pour les décrypter. Avec TLS, le risque est nul car la signature est au moment de la connexion, les calculateurs quantiques ne pourront usurper que les communications futures. Mais, bon, les certificats sont utilisés pour autre chose que TLS, et, comme il faut se préparer à un lent déploiement, il vaut mieux s'y prendre tout de suite.

Notez aussi qu'il n'y a pas que les certificats qui sont signés, les CRL le sont aussi, et ce RFC s'applique aussi à ces listes.

Des deux variantes normalisées dans FIPS-204, « pure » et « HashML-DSA », seule la première est utilisée dans notre RFC, pour les raisons qu'explique la section 8.3.

Le RFC utilise trois niveaux de sécurité différents, et les identificateurs pour les trois niveaux sont id-ml-dsa-44 (OID 2.16.840.1.101.3.4.3.17), id-ml-dsa-65 (OID 2.16.840.1.101.3.4.3.18) et id-ml-dsa-87 (OID 2.16.840.1.101.3.4.3.19). (Ces OID sont enregistrés par le NIST.) D'autre part, l'IANA a enregistré l'identificateur id-mod-x509-ml-dsa-2025 (OID 1.3.6.1.5.5.7.0.119) pour le module ML-DSA (annexe A).

Un certificat X.509 contient des indications sur les utilisations permises (section 4.2.1.3 du RFC 5280). Comme ML-DSA sait faire des signatures mais pas des échanges de clés, un certificat avec ML-DSA aura les utilisations de signature, comme keyCertSign mais pas celles d'échange de clés comme keyEncipherment.

Le format de la clé privée (section 6) a été un des sujets de discussions chauds à l'IETF (et chez les implémenteurs). Dans la norme FIPS-204, on peut définir une clé privée de deux façons, une optimisée (section 4 de la norme) où on ne stocke que la graine (notée ξ) ou bien une forme longue avec la graine, les éléments de la clé secrète, etc. On peut déduire la clé de la graine (section 6.1 de la norme), mais pas l'inverse donc si vous ne gardez pas la graine, vous pourrez toujours signer mais pas retrouver la graine. Le RFC permet de stocker la clé privée de trois façons, la graine seule (la méthode recommandée, cf. section 8.1), la clé seule (déconseillé) ou les deux (voir un exemple plus loin).

Je n'ai pas trouvé de certificat utilisant ML-DSA dans la nature. crt.sh ne permet pas de chercher par algorithme, même dans ses fonctions avancées. Il faudrait écrire son propre client d'examen des journaux Certificate Transparency (RFC 9162) et j'avais la flemme. Donc, on va utiliser OpenSSL 3.5 pour fabriquer des certificats (je n'ai pas testé pour voir s'ils étaient parfaitement conformes au RFC…).

% openssl req -new -newkey mldsa44 -keyout mldsa.key -out mldsa.csr -nodes -subj "/CN=test"
% openssl x509 -in mldsa.csr -out mldsa.crt -req -signkey mldsa.key -days 2001 
Certificate request self-signature ok
subject=CN=test
  

Et hop, nous voilà avec un beau certificat :

% openssl x509 -text -in mldsa.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            54:5b:c0:5d:0e:85:83:43:90:77:93:4f:53:83:e1:38:a2:12:9f:61
        Signature Algorithm: ML-DSA-44
        Issuer: CN=test
        Validity
            Not Before: Feb 17 15:01:53 2026 GMT
            Not After : Aug 11 15:01:53 2031 GMT
        Subject: CN=test
        Subject Public Key Info:
            Public Key Algorithm: ML-DSA-44
                ML-DSA-44 Public-Key:
                pub:
                    15:10:02:cc:d6:ec:53:12:bb:6d:34:23:82:65:ec:
                    …
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                6E:F9:AD:56:9C:AA:60:EF:ED:B7:A1:7B:70:F6:71:55:74:B8:68:B9
    Signature Algorithm: ML-DSA-44
…
  

Autre solution, de plus bas niveau, en découpant les étapes :

# Créer la clé privée
openssl genpkey -algorithm ML-DSA-44 -out private.pem

# Extraire la clé publique (mais on ne s'en servira pas ici)
openssl pkey -in private.pem -pubout -out public.pem

# Créer la demande de signature du certificat
openssl req -new -subj /CN=Test -key private.pem -out cert.csr

# (Auto-)Signer
openssl x509 -req -in cert.csr -signkey private.pem -out cert.pem
Certificate request self-signature ok
subject=CN=Test

# Vérifier
openssl x509 -text -in cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7c:65:cb:17:5b:ed:ee:08:c9:1a:6b:a5:97:da:ac:b8:0e:6e:df:cd
        Signature Algorithm: ML-DSA-44
        Issuer: CN=Test
        Validity
            Not Before: Feb 18 13:24:05 2026 GMT
            Not After : Mar 20 13:24:05 2026 GMT
        Subject: CN=Test
        Subject Public Key Info:
            Public Key Algorithm: ML-DSA-44
                ML-DSA-44 Public-Key:
   …
   Signature Algorithm: ML-DSA-44
…

Et si vous voulez utiliser des extensions comme la restriction d'utilisation du certificat (ici, on se limite à la signature), remplacez la demande de signature et la signature par :

openssl req -new -subj /CN=Test -key private.pem -out cert.csr -addext "keyUsage=digitalSignature"
openssl x509 -req -in cert.csr -signkey private.pem -out cert.pem  -copy_extensions copy
  

Si vous voulez regarder ce qu'il y a dans la clé privée :

%  openssl pkey -text -in private.pem  
…
ML-DSA-44 Private-Key:
seed:
    48:c8:e4:e3:63:16:c0:e4:57:da:22:31:94:36:98:
    ..
priv:
    d9:0b:5b:8d:18:4f:61:8d:c0:8f:85:6c:97:28:46:
    …
  

Vous voyez que sont stockées graine et clé (et la clé publique, plus loin).

Pour wolfSSL, vous pouvez regarder ici.

Pour des « vrais » certificats, notez que Digicert en fait apparemment, ainsi que l'AC pour usage privé d'AWS. Vous connaissez d'autres AC qui permettraient ML-DSA ?

Sinon, l'annexe C du RFC comprend de nombreux exemples de clés et de signatures.

Ce très court RFC normalise la façon d'indiquer la zone quand il faut écrire une adresse IPv6 locale. Il remplace le RFC 6874, et est très différent, notamment parce qu'il ne s'applique plus aux URI.

Les zones sont définies et expliquées dans le RFC 4007. En gros, une adresse IPv6 n'est pas forcément globale, elle peut avoir une signification limitée à une seule zone, une zone étant un ensemble de sous-réseaux contigus, souvent composé d'un seul lien Ethernet. Les adresses locales au lien, par exemple, celles qui sont dans le préfixe fe80::/10, sont dans ce cas, le lien qui les relie forme une zone. Une zone n'a de signification que locale, elle n'a pas de sens sur l'Internet public. Comment préciser la zone dans une interface qui accepte les adresses IPv6 ? La syntaxe de celles-ci est normalisée dans le RFC 4291 et le RFC 5952 mais ne prévoit rien pour la zone. C'est surtout ennuyeux pour les réseaux purement IPv6 (RFC 8925) ou essentiellement IPv6 (draft-ietf-v6ops-6mops). Notre RFC impose donc (section 5) que toute interface qui permet d'indiquer des adresses IP permette également d'indiquer la zone.

Indiquer la zone est utile pour les applications de déboguage (cf. l'exemple avec ping plus loin) ou pour configurer une machine (« ton serveur pour le service XXX est à l'adresse YYY »).

Pour indiquer cette zone, ce RFC normalise l'utilisation d'un %, puis l'identificateur de la zone, après l'adresse. La convention du % est décrite en section 11 du RFC 4007. Si l'interface utilisée pour entrer des adresses IP a un problème spécifique avec le %, le RFC autorise à utiliser le tiret à la place. Et si même cela est impossible, le RFC recommande deux champs, un pour l'adresse seule et un pour la zone. Ici, sur une machine Linux, avec le % :

% ping -c 3 fe80::f437:ded0:7b2:1241%enp1s0 
PING fe80::f437:ded0:7b2:1241%enp1s0 (fe80::f437:ded0:7b2:1241%enp1s0) 56 data bytes
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=1 ttl=64 time=68.0 ms
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=2 ttl=64 time=13.2 ms
64 bytes from fe80::f437:ded0:7b2:1241%enp1s0: icmp_seq=3 ttl=64 time=15.6 ms

--- fe80::f437:ded0:7b2:1241%enp1s0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.175/32.268/68.015/25.296 ms

On teste la machine fe80::f437:ded0:7b2:1241 reliée au réseau identifié par enp1s0 (dans le cas de Linux, c'est le nom d'une interface réseau mais d'autres systèmes d'exploitation peuvent utiliser une syntaxe différente, par exemple identifier les zones par un simple numéro comme le fait Microsoft Windows).

Notez que ce n'est pas ping qui a reconnu et traité l'indication de la zone mais le sous-programme getaddrinfo (RFC 3493). Autrement, on aurait pu utiliser un bricolage pour se connecter à une adresse lien local via une bibliothèque LD_PRELOAD, où l'application n'a pas besoin de connaitre cette syntaxe. Notez que la fonction inet_pton ne va pas accepter les adresses avec indication de zone, il faut utiliser getaddrinfo ou bien, séparement, inet_pton et if_nametoindex.

Autre exemple d'utilisation, comme indiqué plus haut, la configuration d'un équipement, par exemple pour lui indiquer « ton résolveur DNS est fe80::f437:ded0:7b2:1241%enp1s0 ». Ou bien les filtres utilisés pour ne capturer que le trafic d'une machine. Mais tcpdump (ou Wireshark) ne reconnaissent pas actuellement cette syntaxe :

 % tcpdump -n host fe80::f437:ded0:7b2:1241%enp1s0
tcpdump: can't parse filter expression: syntax error
  

(Pour tcpdump, il faudrait faire tcpdump -n -i enp1s0 host fe80::f437:ded0:7b2:1241.)

Plus pittoresque, le système OneNet Marine IPv6 Ethernet Networking Standard de la NMEA utilise uniquement des adresses locales au lien et doit donc absolument utiliser un mécanisme permettant d'indiquer la zone.

Le RFC ne liste pas les différences avec son prédécesseur RFC 6874 car elles sont trop nombreuses. Le principal changement est certainement l'abandon d'une standardisation des zones dans les URI, qui n'avait jamais vraiment marché (cf. draft-schinazi-httpbis-link-local-uri-bcp).