Un fichier ECH valide peut servir le mauvais périmètre

Summary

Un contrôle conforme à RFC 9934 peut démontrer que la clé privée contenue dans un fichier PEM correspond à au moins une configuration publique de la liste. Il ne démontre pas que cette liste a été approuvée pour le bon public_name, le bon ensemble de serveurs, le bon RRSet DNS, le bon jeu de reprise ou la bonne période de rotation.
La pièce manquante est un reçu de déploiement de politique, distinct du fichier secret. Il doit relier l’empreinte canonique de la configuration à l’autorité DNS, à une preuve de couverture du parc, au rôle normal ou de reprise, à la fenêtre de chevauchement et à l’approbateur, sans conserver la clé privée ni publier la liste des noms protégés.

Une réponse exacte à une question trop courte

Le test semble décisif. Les délimiteurs PEM sont reconnus, la clé privée PKCS #8 se décode, l’ECHConfigList est lisible et l’une des configurations contient la clé publique correspondante. Le validateur peut conclure que le fichier est correct.

Cette conclusion est utile. Le but de RFC 9934 est précisément de proposer un format commun aux serveurs TLS construits sur des bibliothèques différentes. Le gestionnaire de clés n’a plus à inventer un emballage propre à chaque produit. Le document impose zéro ou une clé privée, une ECHConfigList, un libellé ECHCONFIG pour la partie publique et une correspondance entre la clé privée, lorsqu’elle est présente, et au moins une entrée de la liste. Il rappelle aussi que seule la liste publique doit aller dans le DNS.

Mais « correct » ne vaut que pour la relation contrôlée. Le fichier prouve qu’une clé peut ouvrir une configuration. Il ne prouve pas que l’équipe qui l’a assemblé avait mandat pour modifier le périmètre ECH d’un service. Il ne nomme pas le propriétaire de la zone DNS, ne décrit pas le groupe de machines qui doit recevoir la clé et ne fixe ni l’entrée en vigueur ni la fin du chevauchement.

La force de la cryptographie favorise ici une confusion. Parce que la preuve interne est solide, on lui prête volontiers une portée institutionnelle. Or une preuve forte sur une proposition étroite reste une preuve étroite. La correspondance mathématique ne transforme pas le fichier en ordre de changement, en inventaire de déploiement ou en décision de confidentialité.

La bonne question opérationnelle comporte donc une seconde moitié : ce fichier est valide, mais pour quel état de service dûment approuvé ?

Une liste contient déjà plusieurs décisions

Une ECHConfigList n’est pas nécessairement un objet unitaire. RFC 9934 autorise plusieurs ECHConfig, ordonnées par préférence décroissante. Elles peuvent porter des extensions ou des public_name différents. Un serveur peut en outre charger plusieurs fichiers, et seulement une partie d’entre eux peut être destinée aux retry_configs.

Ces possibilités facilitent les transitions. Une version ancienne et une version nouvelle peuvent coexister. Un opérateur peut réserver certaines clés à la reprise après rejet. Plusieurs bibliothèques peuvent consommer le même format sans adopter la même configuration interne.

Elles créent aussi des choix que la validité du fichier ne tranche pas. Deux fichiers valides peuvent être distribués à deux moitiés d’un parc alors que le plan exigeait un état commun. Une entrée prévue pour une courte transition peut rester prioritaire. Une autre peut être chargée sur les serveurs mais absente du jeu de reprise. L’ordre peut être bien formé et néanmoins différent de celui que le propriétaire du service avait approuvé.

RFC 9934 précise que le contenu placé après l’ECHConfigList devrait être ignoré. Cette règle protège la simplicité du format, mais interdit de traiter une note libre ajoutée sous le bloc comme un contrat universel. Écrire « uniquement pour le groupe bleu jusqu’à vendredi » après la structure n’oblige ni le parseur, ni l’agent de déploiement, ni le système de contrôle.

L’empreinte du fichier brut n’est pas non plus une identité suffisante. RFC 7468 avertit que les encodages textuels ne sont pas canoniques : espaces, délimiteurs et choix d’encodage peuvent varier. Pour reconnaître l’objet, il faut préciser une normalisation ou calculer l’empreinte de la structure décodée. Puis il faut encore relier cette identité au changement autorisé.

Le périmètre se forme par le partage

RFC 9849 montre où la politique apparaît. Le public_name désigne le serveur faisant face au client, c’est-à-dire l’entité à laquelle le client fait confiance pour mettre à jour la configuration ECH. Le config_id, limité à un octet, aide le serveur à sélectionner une clé candidate.

Aucun des deux champs n’est un registre de mandat. Un public_name syntaxiquement valable ne démontre pas qu’un client, un domaine ou un locataire devait être placé derrière cette frontière. Le config_id n’est pas unique à l’échelle mondiale : il peut être identique chez deux serveurs faisant face aux clients et être réutilisé lorsqu’une ancienne configuration quitte l’ensemble connu. Il sert à la recherche d’une clé, pas à l’archivage d’une décision.

Le choix de partager ou non une configuration contribue directement à l’ensemble d’anonymat. RFC 9849 observe que des configurations distinctes rendent des noms distinguables, tandis qu’une configuration commune à davantage de noms peut agrandir le groupe dans lequel un observateur doit deviner.

Ainsi, une clé et une configuration peuvent parfaitement correspondre alors que le périmètre de confidentialité s’est rétréci. Aucun octet n’est corrompu. L’erreur se trouve dans la distribution : des noms qui devaient rester confondus ont reçu des configurations différentes. Le cas inverse existe aussi. Des locataires qui exigeaient une séparation de garde, de réponse aux incidents ou de responsabilité peuvent être réunis sous une clé commune sans que le fichier devienne invalide.

Il serait trop simple d’en déduire qu’il faut toujours maximiser le groupe. Une grande population améliore l’indistinguabilité, mais concentre le pouvoir de la clé et le rayon d’impact d’une compromission. Une séparation protège parfois une limite contractuelle ou opérationnelle, mais peut révéler une classe plus petite. La décision légitime est celle dont les objectifs, les autorités et les compromis ont été rendus explicites.

Le DNS transforme le contenu en engagement public

Le client ne lit pas le fichier privé. Il apprend la configuration publique par le paramètre ech des enregistrements SVCB ou HTTPS défini par RFC 9848. Le passage de l’objet local à la promesse publique se fait donc dans le DNS.

La contrainte de déploiement est exigeante : toutes les adresses auxquelles mène le TargetName doivent correspondre à des serveurs ayant accès à la clé privée concernée ou faisant autorité pour le nom public. Une seule machine validée ne prouve pas que l’ensemble des adresses répond à cette condition. Un parc peut contenir huit fichiers corrects et un nœud oublié ; la propriété recherchée porte sur le groupe, pas sur l’échantillon.

RFC 9460 ajoute la priorité, AliasMode, ServiceMode, les paramètres obligatoires et la compatibilité. Un RRSet est une collection non ordonnée, mais SvcPriority exprime une préférence. Une chaîne d’alias peut déplacer la fourniture vers un autre domaine. Plusieurs fournisseurs ou points de terminaison peuvent présenter des paramètres différents.

La décision ECH s’étend donc du contenu décodé jusqu’au RRSet, à la chaîne d’alias et à la population d’adresses. Le fichier ne peut pas certifier qu’une modification DNS a été approuvée par le propriétaire de la zone. Il ne peut pas détecter qu’un fournisseur secondaire n’a pas reçu la clé. Il ne sait pas qu’une autorité annoncée par Alt-Svc reste incohérente avec le chemin principal.

RFC 9848 déconseille les ensembles où certaines alternatives utilisent ECH et d’autres non. Un intermédiaire peut bloquer les points ECH et pousser le client vers l’autre branche. Le protocole impose dans certains cas un comportement dépendant de SVCB afin que le repli ne supprime pas la confidentialité. Mais la construction initiale du RRSet demeure une décision humaine et organisationnelle.

Une rotation n’a pas un seul instant

Remplacer le fichier ressemble, sur un diagramme, à une bascule. Pour les clients, il s’agit d’une période. RFC 9849 recommande que l’ensemble connu d’un serveur contienne la configuration actuellement publiée et les précédentes que des clients peuvent encore utiliser à cause du TTL DNS ou d’une mise en cache plus longue.

Pendant le chevauchement, plusieurs vérités coexistent. Le DNS peut annoncer la nouvelle clé. Les serveurs doivent encore accepter l’ancienne. Certains nœuds ont achevé le déploiement, d’autres non. Les retry_configs doivent proposer des clés à jour. Si un client suit une configuration de reprise puis essuie un nouveau rejet, le texte y voit un signe probable d’incohérence.

La cadence elle-même est un compromis. Une rotation rapide réduit la durée d’exposition d’une clé compromise, mais RFC 9849 note qu’elle peut limiter la taille accumulée de l’ensemble d’anonymat. Une longue conservation aide les clients en cache, mais maintient davantage de secrets actifs.

Or le fichier ne porte pas la date de publication DNS, le TTL retenu, le seuil de couverture du parc, la durée d’acceptation de l’ancienne clé, la date de destruction ou l’autorité qui a approuvé l’exception. Deux fichiers peuvent rester valides, alors qu’un seul est légitime pour l’instant considéré.

Une preuve exploitable doit distinguer l’ancien état encore accepté par choix de l’ancien état survivant par oubli. Sans chronologie, un audit tardif ne peut pas expliquer pourquoi une clé répondait mardi mais devait disparaître vendredi.

Ce qui est démontré, ce qui reste à démontrer

Il n’est pas nécessaire de diminuer RFC 9934 pour fixer la limite.

Le fichier peut démontrer que sa structure respecte le format et qu’une clé privée présente correspond à au moins une configuration. Il fournit un objet portable entre gestionnaire de clés et logiciels TLS. Il prévient une catégorie simple d’erreurs de couplage.

À lui seul, il ne peut pas démontrer :

que le public_name choisi représente l’autorité approuvée ;
que le propriétaire DNS a autorisé cette liste pour ce RRSet ;
que toutes les adresses issues du TargetName ont reçu la clé ;
que l’ordre de préférence et le sous-ensemble de reprise sont conformes ;
que les noms censés partager un ensemble utilisent la même configuration ;
que des locataires qui doivent rester séparés ne sont pas réunis ;
que l’ancienne clé subsiste uniquement pendant la fenêtre de cache prévue ;
que le mélange de chemins ECH et non-ECH a été accepté ;
qu’une exception possède un responsable, une échéance et un retour arrière.

Ce sont des faits d’autorité, de distribution et de durée. Les incorporer tels quels au fichier secret serait d’ailleurs une mauvaise solution. L’auditeur doit pouvoir examiner certaines preuves sans devenir dépositaire de la clé.

Un reçu qui n’invente pas un nouveau fichier sensible

Le reçu complémentaire peut commencer par l’empreinte canonique de l’ECHConfigList décodée et le résultat de la correspondance privée/publique. Il ne stocke jamais la clé. Il indique le public_name attendu, les identifiants de configuration et le rôle autorisé de chaque entrée : usage ordinaire, reprise, chevauchement ou retrait.

Il lie ensuite cette empreinte à celle d’un RRSet DNS canonique, avec le propriétaire, le type, le mode, le TargetName, SvcPriority et les paramètres obligatoires. En présence d’un alias ou de plusieurs fournisseurs, il conserve la frontière choisie. Un condensat de cohorte et un résultat de couverture suffisent pour les serveurs ; la liste publique complète des adresses n’est pas nécessaire.

La chronologie enregistre l’approbation, la génération, l’activation, la publication DNS, le début du chevauchement, la première date de retrait sûre, le retrait effectif et la destruction. Le calcul cite le TTL et la marge admise pour les caches persistants. Un contrôle vérifie le jeu ordinaire, le jeu de reprise et le taux de doubles rejets.

La politique d’anonymat doit être visible sans révéler tous les noms. Une classe de séparation, une tranche de taille et un seuil de changement peuvent suffire. Des noms d’essai contrôlés permettent de vérifier la distribution sans transformer l’audit en catalogue de clients.

Enfin, le reçu nomme l’approbateur, la version de politique, l’exception, son échéance, la cible de retour arrière, la version de l’évaluateur et l’état de correction. Une décision rectifiée doit rester lisible comme telle.

Cette séparation est saine : la preuve de décision peut circuler vers le contrôle ; la clé et la population protégée restent limitées. Un dispositif ECH ne devrait pas produire, au nom de l’audit, la carte détaillée qu’il cherche à rendre moins observable.

Limites des preuves disponibles

Les documents étudiés ne décrivent aucun incident chez un opérateur nommé. Ils ne prouvent ni fuite de clé, ni échec de déploiement, ni repli observé, ni taille mesurée d’un ensemble d’anonymat. Ils ne permettent aucune conclusion sur l’adoption du marché ou la conformité juridique.

Le reçu proposé n’est pas une exigence de l’IETF. C’est un contrôle éditorial construit à partir de la différence entre un objet transportable et la décision qui lui donne un périmètre. Un opérateur peut disposer de preuves équivalentes dans son gestionnaire de clés, son système DNS et son inventaire. Il doit seulement pouvoir les relier.

La conclusion reste volontairement limitée : valider le fichier, le protéger comme une clé de serveur, puis vérifier séparément l’autorité et le déploiement. La confidentialité ne réside pas dans le suffixe .pem. Elle apparaît lorsque la bonne configuration rencontre le bon DNS, les bons serveurs, le bon groupe de noms et la bonne période.

Un fichier de clés ECH valide ne prouve pas que le bon périmètre de confidentialité a été choisi

Pourquoi c'est important

Summary

Une réponse exacte à une question trop courte

Une liste contient déjà plusieurs décisions

Le périmètre se forme par le partage

Le DNS transforme le contenu en engagement public

Une rotation n’a pas un seul instant

Ce qui est démontré, ce qui reste à démontrer

Un reçu qui n’invente pas un nouveau fichier sensible

Limites des preuves disponibles

Sources

Contexte approfondi du profil

Strategic Circle

Leadership Alliance

Briefing du Strategic Circle

Briefing Leadership Alliance