Résumé

  • Mise en ligne le 11 septembre, la révision 14 de draft-ietf-dance-client-auth reste un Internet-Draft en Working Group Last Call, et non un RFC adopté.
  • Le nouveau texte énumère quatre résultats autres qu’un ensemble TLSA validé par DNSSEC : échec de validation, réponse non authentifiée, NXDOMAIN et NODATA. Pour chacun, le serveur doit interrompre la connexion ou, si sa politique l’autorise, considérer le client comme non authentifié.
  • Une fiche de décision locale devrait conserver la classe DNS observée, le mode de confiance, la version de politique et l’autorisation finale. Cette proposition éditoriale n’ajoute aucune obligation au projet.

Le détail utile tient dans une modification

Le Datatracker présente « TLS Client Authentication via DANE TLSA records » comme un document actif du groupe DANCE, dans la zone Sécurité de l’IETF. La révision 14 date du 11 septembre 2026 et vise le statut Proposed Standard. Elle n’en bénéficie pas encore : la page affiche In WG Last Call, avec suivi du document shepherd, tandis que l’état IESG attend toujours l’action de l’Area Director.

L’historique permet de ne pas transformer une nouvelle version en nouveau consensus. La révision 13 a été publiée le 23 juillet ; cinq jours plus tard, le document est revenu de Submitted to IESG for Publication à In WG Last Call. Le 11 septembre apporte la révision 14, sans décision finale.

Entre les révisions 13 et 14, le changement substantiel apparaît dans l’étape de recherche DNS du serveur. Le texte ne parle plus seulement d’un échec de validation DNSSEC. Il couvre tout résultat autre qu’un RRset TLSA validé par DNSSEC et cite quatre familles. La précision est petite par sa longueur, importante par ce qu’elle permet de mesurer.

Le client donne le nom, le serveur interroge

DANE a d’abord été défini, par les RFC 6698 et 7671, pour qu’un client évalue le certificat ou la clé d’un serveur à partir d’un enregistrement TLSA protégé par DNSSEC. Le projet DANCE retourne le dispositif vers l’authentification du client.

Dans un échange compatible, le serveur annonce l’extension proposée dane_clientid dans CertificateRequest. Le client qui veut employer DANE renvoie, avec son certificat, le nom propriétaire complet de son enregistrement TLSA. Le serveur ne reconstruit pas ce nom à partir du port ou du transport : il interroge exactement la valeur fournie. Cette mécanique suppose TLS 1.3 ou DTLS 1.3 au minimum.

Le serveur peut valider DNSSEC lui-même jusqu’à une ancre de confiance configurée. Il peut aussi faire confiance à un résolveur validant joint par une liaison sûre et exiger le bit AD. Ces deux architectures ne produisent pas la même provenance, même lorsque leur verdict final est identique.

À la date de recherche, le registre IANA des extensions TLS ne montre pas de valeur attribuée à dane_clientid. Le projet parle lui-même d’une valeur qui sera attribuée. Il faut donc décrire une spécification en cours, sans lui inventer un code ni un déploiement.

Quatre absences, quatre enquêtes

La première classe est l’échec de validation DNSSEC. Des données censées être authentifiées n’ont pas franchi la validation applicable. C’est une observation cryptographique, pas encore la preuve d’une attaque ni l’identification d’un responsable.

La deuxième est une réponse non authentifiée parce qu’une zone n’est pas signée ou qu’une délégation est non sécurisée. L’absence de chaîne sécurisée n’équivaut pas à une chaîne signée devenue invalide. Le vocabulaire du RFC 4033 permet précisément de ne pas confondre zone signée, zone non signée et attente liée à l’ancre de confiance.

Avec NXDOMAIN, le nom demandé n’existe pas. Avec NODATA, le nom peut exister mais aucun enregistrement du type TLSA n’est disponible. Le RFC 2308 fonde cette séparation dans le traitement des réponses DNS négatives. Pour l’équipe qui gère une flotte d’appareils, un identifiant supprimé et un identifiant encore présent mais non provisionné appellent des vérifications différentes.

Le projet ne déclare aucune de ces situations malveillante. Elles peuvent provenir d’un nom ancien, d’une délégation volontairement non sécurisée, d’une publication incomplète ou d’une rupture de validation. Sa retenue est saine : TLS ne doit pas produire un rapport d’incident qu’il n’a pas observé.

En revanche, l’exploitation perd de l’information si elle journalise seulement handshake_failure. Les quatre entrées deviennent un même résultat. Une connexion poursuivie comme non authentifiée peut créer la même opacité sous une apparence de disponibilité.

Deux décisions suivantes ne sont pas du DNS

Un RRset TLSA validé n’authentifie pas encore le client. Le serveur doit comparer les données TLSA au certificat ou à la clé publique présentée, conformément aux modes d’usage, de sélection et de correspondance. Si la comparaison échoue, le projet ouvre de nouveau le choix entre l’abandon et le traitement non authentifié, selon la politique locale.

Une correspondance réussie ne vaut pas non plus autorisation générale. Le texte permet au serveur d’appliquer ensuite ses propres listes d’admission ou règles d’autorisation. Une identité DANE correcte peut rester hors du domaine autorisé. Une session non authentifiée peut continuer vers une ressource publique sans recevoir les droits d’un client reconnu.

Trois états doivent donc rester séparés : résultat DNS, authentification de la clé ou du certificat, décision applicative. Leur réunion dans un unique voyant vert ou rouge efface l’autorité qui a agi.

Une fiche brève, pas un dossier dans TLS

Il serait imprudent de mettre tous les détails dans le protocole. Un nom de client peut désigner une personne ou un appareil ; le projet souligne lui-même le risque de corrélation. La preuve manquante peut rester dans une fiche de décision de recherche, limitée et protégée. Il s’agit de ma proposition éditoriale, pas d’une exigence IETF, DANCE ou IANA.

La fiche lie l’heure, une forme autorisée ou hachée du nom TLSA communiqué, le type de requête, l’une des quatre classes, l’état DNSSEC, le mode de validation local ou délégué, la référence de politique serveur et la branche choisie. Elle ajoute la comparaison du certificat si cette étape a été atteinte, puis l’autorisation applicative. Une étape interrompue porte la mention non atteinte ; elle n’est pas remplie par déduction.

La conservation doit suivre la sensibilité des identités. Des statistiques publiques peuvent montrer la répartition des classes et les changements de politique sans exposer les noms d’appareils ni les historiques de connexion.

Le Policy Mirror de Heng Lu invite à associer acteur, règle et preuve. L’opérateur DNS publie le nom et les enregistrements ; le client annonce l’identité à rechercher ; le serveur choisit son chemin de confiance ; sa politique décide du sort TLS ; l’application attribue ou refuse les droits. La Minimum Initial Specification recommande une règle commune minimale qui laisse les décisions locales évoluer. DANCE 14 respecte cette limite. La fiche empêche seulement que cette liberté efface son propre motif.

Sources

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Historique du document
  3. Révision 13
  4. Révision 14
  5. Groupe de travail DANCE
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — exploitation de DANE
  8. RFC 2308 — réponses DNS négatives
  9. RFC 4033 — introduction à DNSSEC
  10. Registre IANA des ExtensionType TLS
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification