Résumé

  • Le nom propriétaire d’un enregistrement TLSA incorpore le port, le transport et le domaine de base. La preuve obtenue vaut pour ce triplet de service et pour un modèle de validation donné, non pour l’hôte entier.
  • Un audit rejouable doit conserver le chemin DNSSEC, le nom interrogé, l’usage du certificat, le sélecteur, le type de correspondance, le matériau présenté et la règle applicative. La seule mention « DANE valide » est trop pauvre pour porter une décision.

Le port de secours n’hérite de rien

Prenons un cas de contrôle fictif. service.example présente le même certificat sur les ports TCP 443 et 8443. La zone signée publie un jeu TLSA utilisable sous _443._tcp.service.example, mais rien d’équivalent pour 8443. Le client du premier service valide DNSSEC et trouve l’association attendue. Celui du second doit former _8443._tcp.service.example; il n’a aucune raison d’importer la décision précédente.

L’exemple ne décrit aucun produit particulier. Il met à l’épreuve une phrase dangereusement commode : « ce certificat a déjà été validé par DANE sur cette machine ». Le RFC 6698 ne crée pas une réputation attachée à la machine. Il place volontairement le numéro de port et le protocole de transport dans le nom DNS afin que deux services voisins puissent appliquer des règles différentes.

Une plateforme qui mémorise uniquement l’empreinte du certificat et le nom d’hôte transforme une autorisation localisée en attribut global. Au moment d’un incident, elle saura peut-être retrouver la clé, mais plus le service pour lequel cette clé avait été publiée.

Il faut pouvoir reconstruire le nom interrogé

Dans le cas direct le plus courant, le client construit _port._tcp.domaine-de-base. Le numéro de port est décimal. Le libellé de transport sépare TCP des autres mécanismes. Quant au domaine de base, il est déterminé par le protocole applicatif ; ce n’est pas un champ libre choisi après coup par l’équipe de journalisation.

Les redirections compliquent cette provenance. Un CNAME peut déplacer la résolution de l’enregistrement. Un protocole fondé sur SRV suit le modèle précisé par le RFC 7673. Pour SMTP, la découverte MX, le domaine TLSA de base, les identifiants de référence et le traitement des erreurs suivent le RFC 7672. L’adresse IP finale ou le nom affiché dans un socket ne suffit donc pas toujours à établir l’origine de l’autorité.

Le dossier minimal comprend la destination demandée par l’application, les étapes MX, SRV ou CNAME, les noms avant et après expansion, le port, le transport, le nom TLSA final, l’état DNSSEC et la règle normative reliant ces éléments. Sans cela, un tiers ne peut pas reproduire le verdict.

Le champ usage choisit une constitution de confiance

Le premier octet des données TLSA distingue quatre décisions. PKIX-TA(0) contraint une autorité de certification tout en maintenant la validation PKIX. PKIX-EE(1) impose une association avec le certificat terminal, là encore dans un chemin PKIX valide. DANE-TA(2) publie une ancre de confiance au moyen de DNSSEC. DANE-EE(3) associe directement le service à un certificat terminal ou à sa clé.

La correspondance des mêmes octets ne rend pas ces usages interchangeables. Avec PKIX-EE, un certificat expiré ne devient pas valable simplement parce que son matériau correspond. Avec DANE-EE, le client ne doit pas inventer des contrôles de nom étrangers au profil de l’application. SMTP DANE restreint encore les choix : son modèle opportuniste ne repose pas sur les usages PKIX comme le ferait un navigateur.

Le contrôle utile pose donc plusieurs questions : quel usage a été publié, par quelle zone signée, pour quel service, quelle implémentation l’a compris et quelle politique applicative a décidé de l’échec ou du repli ?

Sélecteur et type de correspondance ne sont pas des détails

Le sélecteur 0 vise le certificat DER complet. Le sélecteur 1 vise le SubjectPublicKeyInfo, c’est-à-dire la clé publique et son algorithme. Un renouvellement peut produire un nouveau certificat avec la même clé : le premier objet change, le second peut rester identique.

Le type de correspondance 0 compare les octets sélectionnés ; le type 1 leur condensat SHA-256 ; le type 2 leur condensat SHA-512. Une chaîne hexadécimale isolée ne révèle donc ni l’objet choisi ni l’opération appliquée.

Ces options répartissent le coût de la rotation. L’association au certificat complet est étroite, mais exige une mise à jour lors de chaque renouvellement. L’association au SPKI simplifie un renouvellement à clé constante, mais étend les conséquences d’une clé compromise. Une ancre DANE couvre encore un autre périmètre. Le bon choix dépend de la garde des clés, du processus de déploiement et de la capacité de retour arrière.

DNSSEC décide si la publication peut faire autorité

Un paquet DNS contenant un RR de type 52 n’est pas encore une preuve DANE. Le validateur doit qualifier la réponse comme secure, insecure, bogus ou indeterminate. Un Extended DNS Error peut expliquer un échec ; il ne remplace pas la chaîne DS, DNSKEY et RRSIG.

Une réponse TLSA non signée ne peut pas affaiblir la validation du certificat. Inversement, si un profil applicatif considère un jeu sécurisé et utilisable comme un engagement, le repli silencieux après échec réintroduit le déclassement que DANE devait empêcher. En SMTP DANE, un serveur dont l’association sécurisée ne correspond pas ne doit pas recevoir le message par cette voie.

DNSSEC authentifie la publication sous un nom. Il ne prouve ni la possession exclusive de la clé privée ni la bonne configuration de l’application. La compromission de la signature DNS peut publier un nouveau DANE-EE ; la compromission de la clé TLS peut satisfaire l’ancien. Les deux plans de contrôle doivent avoir des responsables et des traces séparés.

Le protocole applicatif reste souverain sur son action

Une réussite TLSA établit qu’un matériau sélectionné dans la poignée de main satisfait une association. Elle ne prouve pas qu’ALPN a choisi le bon protocole, que l’autorité HTTP est admissible, qu’un client est authentifié ou qu’une transaction est autorisée.

La frontière réapparaît aussi au proxy. Une terminaison TLS validée peut être suivie d’une connexion interne sans rapport cryptographique avec la première. De même, un certificat terminal partagé entre serveurs fonctionnellement différents élargit les possibilités de substitution. Le RFC 7672 recommande d’éviter ce partage lorsque les serveurs ne sont pas équivalents.

La formulation défendable est précise : « le SPKI présenté correspondait à un TLSA usage 3 sécurisé pour ce nom de service à cet instant ». « Le domaine a autorisé la requête » ne l’est pas.

Une rotation est une période de coexistence

La nouvelle association doit généralement être publiée avant d’être indispensable. Ancien et nouveau matériaux coexistent pendant que les caches, les signatures DNSSEC et les terminaux convergent. Le retrait ne devient raisonnable qu’après des observations depuis plusieurs résolveurs et réseaux.

Un renouvellement conservant la clé peut laisser un SPKI inchangé ; une rotation de clé ne le peut pas. Une ancre de confiance n’obéit pas au même calendrier qu’un certificat terminal. Une seule observation verte ne mesure pas ces différences.

Il faut dater la publication autoritative, la visibilité dans les caches, le déploiement de la clé ou du certificat, le retrait de l’ancien matériau et la validité des signatures. Sans cet axe temporel, une transition correcte et une panne transitoire produisent le même résumé.

Tester en franchissant volontairement la limite

Présentez le même certificat sur deux ports et ne publiez TLSA que pour l’un. Changez le transport. Introduisez CNAME, SRV puis MX. Rendez le chemin PKIX invalide sous usage 1 tout en gardant les octets correspondants. Renouvelez avec la même clé, puis changez de clé pendant une période de chevauchement.

Faites ensuite varier les états secure, insecure, bogus et indeterminate, ainsi que l’historique des caches. Enfin, laissez TLSA réussir et faites échouer ALPN ou l’autorisation applicative. Le système doit conserver ces verdicts séparés.