Résumé

  • La RFC 9934 normalise un fichier PEM composé de zéro ou une clé privée PKCS #8, puis d’une unique ECHConfigList; si la clé existe, une configuration publique de la liste doit lui correspondre.
  • Cette cohérence interne ne dit pas quelle génération le serveur a chargée, ce que le DNS publie, ce que le client a conservé, ni si ECH a été accepté et a produit l’effet de confidentialité attendu.

Le procès-verbal de changement indiquait « rotation terminée » à 02 h 00. Le gestionnaire de clés avait produit le secret à 01 h 52, le fichier avait été copié à 01 h 57, la zone DNS publiée à 02 h 03, et le serveur n’avait relu sa configuration qu’à 02 h 11. Entre-temps, des résolveurs conservaient encore l’ancienne liste. Aucun de ces événements n’était faux. C’est le mot « terminée » qui l’était.

La RFC 9934 fixe un contrat de représentation afin que des serveurs et bibliothèques TLS différents puissent recevoir le même type de paquet ECH. Le fichier contient zéro ou une clé privée, puis une ECHConfigList. La clé, lorsqu’elle est présente, porte l’étiquette PRIVATE KEY, suit PKCS #8 et précède la liste. La liste publique porte l’étiquette ECHCONFIG et encode en base64 la valeur publiable dans un enregistrement HTTPS. Une configuration de la liste doit correspondre à la clé privée présente.

La norme ne dit pas que toute liste doit être accompagnée d’un secret. Le cas sans clé privée permet de transporter la projection publique. Elle interdit surtout une confusion dangereuse : seule l’ECHConfigList va dans le DNS; la clé privée ne doit jamais y être publiée. Le même état logique possède donc deux projections aux droits radicalement différents. Les regrouper sous une opération de copie unique détruit soit la confidentialité, soit la traçabilité.

Une liste peut contenir plusieurs ECHConfig, par ordre de préférence décroissant. Plusieurs fichiers peuvent être configurés et seule une partie de leurs listes peut alimenter retry_configs. Le test « la clé correspond à un membre » reste volontairement limité. Il ne certifie ni les autres membres, ni le choix actif du processus, ni la publication observée par un client.

La RFC 7468 rend les enveloppes textuelles interopérables, malgré les divergences historiques de parseurs. Une étiquette et une base64 correctement lue établissent une syntaxe. Elles ne constituent ni un reçu de déploiement, ni un registre de garde. La RFC 4648 explique l’encodage; elle ne donne aucun sens opérationnel aux octets.

La RFC 9849 montre pourquoi le temps compte. Le serveur tourné vers le client devrait conserver les configurations actuellement publiées et les précédentes, susceptibles de rester en cache pendant un TTL ou davantage. S’il déchiffre le ClientHello interne, ECH peut être accepté. Sinon il poursuit avec le ClientHello externe, rejette ECH et peut proposer une liste de reprise à jour. Le client doit distinguer cette reprise d’une connexion utilisable par l’application.

Il faut donc suivre au moins trois calendriers. Le calendrier secret couvre génération, installation, lecture par le processus et retrait. Le calendrier public couvre publication faisant autorité, propagation et expiration. Le calendrier client couvre sélection, tentative, acceptation, rejet et reprise. Une rotation sûre est l’intersection démontrée de ces calendriers, pas l’heure affichée par le dernier job.

Le dossier de preuve doit garder le hachage exact du fichier, le résultat du parseur, la cardinalité et la correspondance cryptographique, les capacités réelles de lecture, le reçu de copie, la preuve de rechargement, l’ensemble actif du serveur, la valeur HTTPS/SVCB faisant autorité, plusieurs observations récursives avec leur âge, le config_id proposé, l’acceptation ou le rejet, la liste de reprise, la validation du certificat et l’observation applicative. Le secret lui-même ne doit pas migrer dans le journal.

La RFC 9848 limite aussi la promesse. Un ensemble mêlant des destinations ECH et non-ECH peut subir une dégradation par blocage sélectif. Le nom peut rester visible dans le DNS, être inféré par l’adresse ou le trafic, ou appartenir à un ensemble d’anonymat trop petit. La RFC 9460 décrit le lien de service public, pas la capacité secrète du serveur.

La priorité au code en fonctionnement de Heng Lu ne consiste pas à préférer la mémoire du serveur à toute autre vérité. Elle consiste à donner à chaque observation sa bonne compétence. Le parseur sait ce qu’il a lu. Le processus sait quelles clés il a chargées. Le DNS sait ce qu’il sert. Le client sait quelle négociation il a vécue. Aucun ne peut signer seul le résultat de confidentialité complet.

Une spécification initiale minimale est précisément adaptée ici. Le format commun reste simple et testable; les opérateurs conservent la liberté de choisir leur gestionnaire, leur TTL, leur mécanisme de rechargement et leur période de chevauchement. Cette liberté s’accompagne de la responsabilité de publier les décisions et de mesurer leurs effets.

Sources