Résumé

  • Une chaîne TLSA validée peut créer, pour un nom SNI et un port, une durée de prise en charge de l’extension. Le TTL conserve la maîtrise de la fraîcheur du TLSA ; la durée plus longue oblige le serveur à rendre une situation DNSSEC vérifiable.
  • Un déni d’existence valide, une délégation devenue non sécurisée ou une transition validée vers la valeur zéro peuvent lever le verrou. L’omission de l’extension pendant qu’il reste actif n’est pas un déni et peut imposer l’arrêt de la connexion.

Le résolveur qui devait se prouver lui-même

L’un des cas d’usage de RFC 9102 commence par un cercle. Un client veut authentifier en DANE le résolveur DNS-over-TLS qu’il s’apprête à utiliser. Or les enregistrements TLSA et leur chaîne DNSSEC sont normalement obtenus par DNS. Comment interroger avec confiance un service qui n’a pas encore été authentifié ? L’extension expérimentale dnssec_chain permet au serveur d’embarquer cette chaîne dans la poignée de main TLS.

Cette réponse réunit deux temporalités. La chaîne dit si, maintenant, le TLSA du nom et du port demandés est signé jusqu’à un point d’ancrage DNSSEC et correspond au certificat présenté. Le champ ExtSupportLifetime, exprimé en heures, indique pendant combien de temps le serveur — ou l’ensemble de serveurs derrière le même nom — s’engage à continuer de prendre en charge l’extension.

Shumon Huque cosigne RFC 9102 avec Viktor Dukhovni, Willem Toorop, Paul Wouters et Melinda Shore ; le texte attribue l’idée initiale à Adam Langley. Son profil IETF et sa biographie publique situent ses travaux dans le DNS, les réseaux et les protocoles de sécurité, chez Salesforce après Verisign et l’Université de Pennsylvanie. Cette trajectoire explique la pertinence du regard, sans transformer un RFC collectif et expérimental en invention individuelle.

Le verrou ne naît pas d’un simple nombre

Un attaquant ne doit pas pouvoir poser lui-même un verrou en injectant une valeur. Le client ne peut retenir une durée non nulle qu’après une poignée de main entièrement validée : l’extension contient une chaîne TLSA correcte et cette dernière authentifie le certificat du serveur selon DANE. Une réussite PKIX ordinaire, des RR seulement bien formés ou une valeur reçue sans validation ne suffisent pas.

La portée est tout aussi précise. La demande fournit le port TCP et le nom vient de SNI. Dans cette méthode embarquée, le serveur ne développe pas le CNAME du nom SNI pour choisir la base TLSA. Le souvenir local appartient donc au couple nom-port. Il n’englobe ni toutes les adresses d’un hôte ni tous les locataires d’une infrastructure mutualisée.

Le client peut réduire la durée annoncée selon sa politique. RFC 9102 évoque le risque théorique d’un serveur compromis qui proposerait le maximum de sept ans. À l’inverse, plafonner trop bas raccourcit la protection contre le déclassement. La durée reçue est une offre de continuité, acceptée sous une limite locale.

Deux horloges qui ne doivent jamais être confondues

Le TLSA validé reste réutilisable jusqu’à son TTL. Tant qu’il est frais, le client peut l’employer sans redemander la chaîne à chaque connexion. Quand ce TTL arrive à échéance alors que le verrou de prise en charge court toujours, une nouvelle preuve devient nécessaire.

Le TTL et l’expiration RRSIG protègent donc la fraîcheur du contenu ; ExtSupportLifetime protège la disponibilité future du mécanisme qui donnera le prochain contenu. Une longue promesse ne prolonge aucune signature DNSSEC. Un TTL court n’annule pas l’engagement de service. Conserver une seule date d’expiration dans la télémétrie rendrait le système incompréhensible.

La reprise de session TLS constitue encore un état distinct. RFC 9102 précise qu’elle ne transporte pas dnssec_chain ; en TLS 1.3, le message Certificate auquel la chaîne serait attachée n’est pas renvoyé. L’absence est alors normale si le client dispose encore du matériau valide nécessaire. Le journal doit distinguer reprise, poignée de main complète, cache TLSA et attente imposée par un verrou.

Un déni signé répond ; le silence esquive

Le domaine peut décider de supprimer son TLSA. Le serveur est alors capable de fournir une chaîne DNSSEC prouvant l’absence authentifiée de l’enregistrement pour le nom et le port concernés. Une fois validée, cette preuve lève le verrou. Une preuve de délégation non sécurisée peut jouer le même rôle. La politique locale choisit ensuite PKIX ou la fermeture.

Si, au contraire, un client encore verrouillé n’a plus de TLSA frais et ne reçoit aucune extension, il ne peut pas traduire ce silence en « aucun TLSA ». Il doit interrompre ou différer l’échange, puis obtenir hors bande un TLSA valide ou une preuve négative valide. S’il échoue, la connexion s’arrête. Sans cette règle, un serveur détourné muni d’un certificat PKIX acceptable pourrait masquer les données DANE et provoquer le déclassement même que le mécanisme veut détecter.

RFC 9102 le dit sans ambiguïté : exiger l’extension n’équivaut pas à exiger DANE, TLSA ou DNSSEC pour toujours. L’opérateur de zone peut retirer le TLSA, voire le DS. Pendant la durée restante, le serveur doit pourtant livrer l’état vérifiable correspondant. La réponse peut changer ; sa provenance ne peut pas devenir muette.

Sortir exige zéro, puis l’attente

La désactivation suit un ordre. Le serveur commence par annoncer une durée zéro au cours d’une poignée de main authentifiée par DANE. Il maintient ensuite l’extension jusqu’à l’expiration de toutes les durées non nulles précédemment émises. Ce n’est qu’après cette borne externe qu’il peut cesser de répondre. Le TLSA peut disparaître auparavant, à condition que le déni authentifié reste disponible aux clients encore verrouillés.

Dans l’hébergement, cet ordre traverse plusieurs propriétaires. Le client contrôle son nom DNS, tandis que le fournisseur peut gérer le certificat, les nœuds TLS et la construction de la chaîne. Le RFC recommande donc qu’une durée non nulle résulte d’un accord mutuel. Un seul nœud de grappe incapable de servir la preuve peut transformer l’équilibrage de charge en panne intermittente.

Enfin, le serveur ne se confère pas lui-même la confiance en transportant la chaîne. Le client part d’un point d’ancrage DNSSEC configuré, maintient ce point lors des rotations et dispose d’une heure assez juste pour vérifier les RRSIG. L’extension supprime une recherche extérieure ; elle ne supprime ni l’ancrage ni le temps.

Le statut expérimental est essentiel. Le groupe TLS avait soulevé le coût de déploiement du verrou, et RFC 9102 présente l’expérience comme un moyen de l’étudier. Les sources publiques examinées ne mesurent pas son adoption actuelle. Elles documentent en revanche une discipline durable : une affirmation positive, une négation authentifiée et l’absence de réponse sont trois états opérationnels, pas trois apparences d’un même résultat.

Sources