Résumé

  • Un RRset TLSA ne devient une preuve DANE qu’avec son résultat DNSSEC : les données non sécurisées ou indéterminées sont inutilisables, les données bogus imposent l’échec.
  • L’usage du certificat, le sélecteur et le type de correspondance déterminent ce qui est comparé et quelles règles de validation s’appliquent.
  • Une association publiée de manière sûre peut rester inutilisable ou ne pas correspondre au certificat ou à la clé réellement présenté par le serveur.
  • Le contrôle doit distinguer les états publié, sécurisé, utilisable, correspondant et accepté.

Imaginons qu’un certificat de service soit renouvelé à minuit. La nouvelle chaîne est active sur tous les serveurs, mais certains clients conservent en cache une association TLSA visant l’ancienne clé publique. Le DNS contient bien un TLSA, le point HTTPS paraît sain et le ticket est fermé. Ces clients interrompent pourtant la connexion, car l’association authentifiée ne correspond plus à la clé servie.

Cette trace est hypothétique. Elle illustre l’écart entre publier une association et réconcilier tous les éléments nécessaires à l’acceptation.

La publication n’est que le premier état

La RFC 6698 construit TLSA avec quatre éléments : usage du certificat, sélecteur, type de correspondance et données d’association. Les trois paramètres définissent si l’association contraint une chaîne d’AC publique, fournit une ancre de confiance ou désigne un certificat final émis par le domaine ; si la comparaison porte sur le certificat complet ou sur SubjectPublicKeyInfo ; et si les données sont exactes, hachées en SHA-256 ou en SHA-512.

Le nom de la ressource dépend aussi du port, du transport et du domaine de base TLSA. Interroger le mauvais nom de service ou s’arrêter à un alias non sécurisé peut produire des octets DNS valides pour une mauvaise décision. La RFC 7671 intègre l’expansion CNAME sécurisée au choix du domaine de base. Un inventaire qui ne conserve que le RDATA perd donc l’identité du service concerné.

DNSSEC donne ou retire la parole à l’association

Pour la RFC 6698, l’état de validation DNSSEC est déterminant. Un RRset TLSA sécurisé doit servir d’association, sauf interdiction de politique locale. Une réponse bogus doit empêcher ou interrompre TLS. Un RRset non sécurisé ou indéterminé ne peut pas authentifier TLS.

« Présent dans le DNS » est ainsi plus faible que « validé sécurisé ». Et sécurisé ne signifie pas encore utilisable. Une valeur d’usage, de sélecteur ou de type inconnue rend l’association inutilisable, tout comme des données mal formées ou un algorithme jugé trop faible par le client.

Si aucune association utilisable n’est obtenue, l’application traite TLS normalement, sans apport de TLSA. S’il en existe une ou plusieurs, elle effectue les comparaisons imposées et doit en trouver une qui réussit. Deux clients aux fonctions ou politiques différentes peuvent donc traiter différemment le même RRset sans nier sa publication.

Le certificat servi doit encore satisfaire la règle

L’usage choisi modifie le sens de la correspondance. Certains usages conservent la validation PKIX ; les usages DANE peuvent définir une ancre issue du DNSSEC ou associer directement l’entité finale. Le sélecteur décide si un renouvellement gardant la même clé continue de correspondre ou si chaque octet du certificat compte.

La RFC 7671 ajoute les contraintes d’exploitation. DANE-TA exige que le serveur fournisse une chaîne suffisante et, dans certains cas, le certificat de l’ancre. DANE-EE avec sélection SPKI peut survivre au renouvellement lorsque la clé reste identique, mais échoue si une autre clé est servie. L’agilité de hachage ne s’applique qu’après le retrait des associations mal formées ou non prises en charge.

La santé du serveur ne suffit donc pas à prouver la santé DANE. Un client PKIX classique peut réussir quand un client DANE doit rejeter. À l’inverse, une application opportuniste peut poursuivre avec TLS non authentifié faute d’association utilisable, alors qu’une politique obligatoire interdit la connexion. L’acceptation appartient au client et à son protocole.

Le temps sépare aussi publication et acceptation

TTL de TLSA, validité RRSIG, âge du cache et ordre du déploiement bornent l’observation. La RFC 7671 avertit qu’une association obsolète en cache peut faire échouer les clients après une modification imprévue du certificat ou de la chaîne. Une longue durée de signature prolonge aussi la période pendant laquelle des données signées peuvent être rejouées.

La rotation doit coordonner anciennes et nouvelles associations, publication faisant autorité, secondaires, caches de validateurs, déploiement du service et retour arrière. Voir le nouvel enregistrement sur un serveur faisant autorité ne prouve pas ce que voient les clients réels.