Résumé

  • draft-ietf-dance-client-auth-14 fait transmettre au client TLS 1.3 le nom propriétaire complet de son enregistrement TLSA; le serveur interroge ce nom, valide DNSSEC puis compare l’enregistrement au certificat ou à la clé publique brute.
  • La concordance établit une relation bornée entre nom, donnée DNS et clé. L’affectation du sujet, l’admission par le serveur, le droit d’effectuer une opération et son résultat exigent d’autres preuves.

Le protocole proposé commence par un échange asymétrique. Le serveur annonce sa capacité dans CertificateRequest au moyen d’un dane_clientid vide. Le client qui souhaite utiliser DANE renvoie le même type d’extension dans son message Certificate, mais avec le nom propriétaire complet de son TLSA. Le serveur ne construit pas ce nom: il interroge exactement celui qu’il a reçu.

Si la réponse forme un ensemble TLSA validé par DNSSEC et si l’un des enregistrements correspond au certificat ou à la clé publique présentés, la possession de la clé privée est authentifiée dans ce contexte. La conclusion s’arrête là. Un nom signé ne dit pas si l’appareil est encore affecté au même client, si un compte a été fermé, si ce domaine figure dans la liste admise ou si une action est autorisée dans l’application.

Un deuxième Last Call, avec un désaccord ouvert

Le texte actuel est la révision 14, datée du 11 septembre 2026. Le Datatracker la présente comme un Internet-Draft actif du groupe DANCE visant Proposed Standard. Le 15 septembre, l’IESG a lancé un deuxième IETF Last Call, clos le 29 septembre. Ce statut n’est ni une approbation, ni un RFC, ni une preuve de déploiement.

Deux examens contemporains aboutissent à des jugements différents. Le Security Directorate l’a déclaré Ready, avec des remarques mineures sur le traitement d’une extension irrégulière et l’explication des clés publiques brutes. Le DNS Directorate l’a déclaré Not ready. Il estime que les formes _service et _device ne respectent pas encore l’enregistrement des noms soulignés imposé par le RFC 8552, et critique l’explication du format texte et des 255 octets de ClientName.

Ces observations appartiennent à l’état du dossier. L’article ne peut pas arbitrer à la place de l’IESG. La valeur de l’extension reste TBD et le projet demande une inscription IANA marquée Recommended=N, parce que les usages sont spécifiques.

Le DNS authentifie une donnée, pas toute la signification du nom

Pour un serveur DANE classique, le vérificateur dérive souvent le propriétaire TLSA du port et du transport. Ici, les applications peuvent nommer leurs clients de manières différentes. Le client fournit donc le nom entier. Le projet propose des formes propres à un service, à un appareil ou libres, sans imposer une sémantique universelle.

Le serveur doit obtenir un RRset TLSA authentifié. Il peut valider lui-même la chaîne jusqu’à un trust anchor configuré, ou faire confiance à un résolveur validant joint par un canal sûr et à son bit AD. Une zone non signée, une délégation non sûre, un échec DNSSEC, NXDOMAIN ou NODATA ne donnent pas une preuve TLSA. La politique décide ensuite de couper la connexion ou de traiter le client comme non authentifié.

Avec DANE-EE usage 3, la correspondance peut viser directement le certificat ou la clé, sans nom dans le certificat. Avec DANE-TA 2 et PKIX 0/1, ClientName doit aussi correspondre à un dNSName du Subject Alternative Name selon le RFC 7671. Les clés publiques brutes suivent le RFC 7250. Chacune de ces branches définit une preuve d’authentification, non une permission métier.

Conserver la chaîne des décisions

Un journal exploitable doit distinguer le ClientName reçu, la question DNS, le TTL, le validateur et son trust anchor, les champs TLSA, la branche de comparaison, l’empreinte du certificat ou du SPKI, la règle d’affectation du nom, la version de la liste d’accès, la décision applicative et l’effet observé.

Ces horloges divergent. Un TLSA en cache peut rester valide après la réaffectation d’un équipement. Une négociation TLS peut réussir alors qu’un domaine n’est pas admis. Une session admise peut se voir refuser une ressource ou une opération. Une opération autorisée peut encore échouer ou être annulée en aval. Réduire ces étapes à «client authentifié» détruit précisément l’information nécessaire à l’audit.

Enfin, TLS 1.3 chiffre le message Certificate, mais la résolution DNS consécutive peut exposer le nom du client si le DNS chiffré manque. La minimisation QNAME du RFC 9156 limite certaines divulgations. Une requête observée constitue un indice d’exposition, pas la preuve d’une compromission ou d’une utilisation malveillante.