Résumé

  • La révision 12 est un Internet-Draft expérimental actif, ni RFC ni preuve de mise en œuvre.
  • Le document HTTPS exprime un état souhaité ; l’inscription et la politique de chaque fabrique conservent l’autorité d’écriture DNS.
  • Une conversion locale réussie ne prouve pas que les autres fabriques, autorités, caches ou clients possèdent le même RRset.
  • Le retrait, les erreurs invisibles et la couverture multi-endpoint exigent des contrôles explicites.

Le même input peut produire deux zones

SVCB et HTTPS permettent au DNS de distribuer des paramètres de service. Lorsque les clés ECH tournent dans un système distinct de la zone, origin-svcb propose une passerelle : l’origine expose un JSON, une fabrique le récupère, le valide et le transforme.

La passerelle n’impose pas une politique unique. Une fabrique peut comprendre un SvcParamKey qu’une autre refuse. Elle peut corriger une erreur commune ou ajuster le TTL selon une règle locale. Deux fetches HTTPS valides peuvent donc mener à deux états autoritatifs.

La réconciliation doit comparer la sémantique des RRsets générés, la version de politique et les serials. Le hash du document brut ne suffit pas : espaces et ordre JSON peuvent changer sans effet, tandis qu’une transformation locale peut changer le DNS.

L’origine propose, l’opérateur délègue

Par défaut, une fabrique ne devrait pas synthétiser de records depuis les documents découverts. L’activation devrait nécessiter une configuration de l’opérateur. Le fichier public n’est pas une délégation automatique.

L’inscription fixe l’origine, le port, le nom propriétaire, le type, la politique et le responsable. Pour des noms SVCB arbitraires, aucune origine HTTP n’est généralement autorisée par nature ; il faut associer explicitement URL complète ou source locale.

Cette inscription doit être commune ou conciliée entre fabriques. Sinon chacune peut croire agir correctement tout en servant une population différente.

Un port ne parle pas pour son voisin

Le mécanisme permet à une origine de parler pour elle-même. Un service sur 8443 exige le well-known de cette origine lorsque la fabrique traite le nom préfixé par le port. Le document de 443 ne découvre pas un autre service du même hôte.

Les aliases et intermédiaires ne suppriment pas cette frontière. L’origine qui utilise un CDN reste responsable de la fidélité de son JSON.

En split mode, le backend reçoit des paramètres du client-facing server puis publie son propre choix. L’authentification HTTPS du backend et celle du transfert amont sont deux reçus.

Le refus doit devenir visible

L’objet contient regeninterval et endpoints; les clés inconnues au sommet sont ignorées, la liste vide est une erreur. ServiceMode ou AliasMode doivent encore produire un fragment conforme à SVCB/HTTPS.

Si la conversion ou la validation échoue, la fabrique ne doit pas mettre à jour le DNS. Cette protection peut rester invisible à l’origine. Sans rapport, celle-ci continue à tourner ses valeurs tandis qu’une autorité garde l’ancienne génération.

Le journal conserve certificat, body hash, parse, normalisation, champs rejetés, RRset, politique et décision. Il distingue absence de changement, changement invalide et changement valide refusé.

Une liste demande une couverture

La fabrique devrait tester ECH avec les endpoints avant publication, parfois grâce à un client capable d’utiliser une configuration non publiée.

Une ECHConfigList peut contenir des échecs GREASE intentionnels. Un déploiement multi-CDN peut présenter plusieurs adresses alors que le test n’en atteint qu’une. Les hints différents de A/AAAA nécessitent une authentification webPKI sur toutes les adresses pertinentes.

Le reçu énumère endpoint, famille, index ECHConfig, attente GREASE, certificat, ALPN, port et résultat. Un succès sans dénominateur ne valide pas la liste.

Les horloges ne tournent pas ensemble

regeninterval décrit une fréquence possible, pas une expiration stricte. Le TTL devrait être plus court et le rafraîchissement tenté à temps. Mais génération, polling, commit, réplication, caches récursifs et clients suivent leurs propres horloges.

retry_configs permet un chevauchement utile. Une rotation ne peut donc être déclarée au moment où le JSON change. Des sondes sur plusieurs autorités et chemins clients doivent fermer la preuve.

Une seule fabrique réussie n’est pas davantage une convergence. La divergence doit bloquer ou être acceptée explicitement avec une portée connue.

Quitter le mécanisme reste un acte de gouvernance

Le projet ne définit ni l’ajout ou le retrait d’une origine de la liste de polling, ni la demande de suppression de tous les records HTTPS. Un JSON ancien peut continuer à être publié après le départ.

Un 404 ne constitue pas forcément un ordre de suppression : il peut être transitoire. Conserver sans limite est aussi dangereux. Le retrait exige autorité, date, remplacement, serial et observation des caches.

La politique de panne peut différer pour ECH, hints et aliases. Elle doit être décidée avant l’incident.

Le client ne doit pas court-circuiter le DNS

Même public, le well-known ne doit pas remplacer la requête HTTPS/SVCB d’un client général. La connexion de bootstrap ne peut pas utiliser ECH et révèle le nom protégé.

L’origine pourrait aussi fournir une configuration unique, créant un identifiant. La distribution DNS mutualise autrement les réponses et les politiques.

Le reçu client garde resolver, génération, âge, endpoint, ECHConfig, handshake et résultat. Le fetch JSON appartient au contrôle opérateur.

Une compromission brève peut durer

De mauvaises valeurs peuvent provoquer fuite de confidentialité ou abus de retry_configs. Puisque webPKI s’appuie parfois sur DNS ou HTTP, une compromission temporaire du backend pourrait influencer des hints et prolonger son effet dans une chaîne faible.

C’est un modèle de menace, pas un incident établi. Les hints divergents sont comparés à A/AAAA et authentifiés. CAA peut compléter l’analyse. Routage et identité ne doivent pas dépendre de la même entrée compromise.

Un service de fichiers doit également empêcher traversal et énumération qui exposeraient les clés privées ECH à côté du JSON public.

Sources et limites

Le dossier réunit la révision 12, les pages officielles, TLS WG, SVCB/HTTPS, bootstrap ECH, ECH, well-known URI, TLS 1.3, ACME, CAA, registres IANA et key-share prediction.

Ces sources établissent textes et risques. Elles ne prouvent aucune fabrique, publication, convergence, ECH, certificat, traçage, compromission ou issue applicative. L’ouverture est construite.

Sources