4. Utilisation des enregistrements TLSA dans TLS (Use of TLSA Records in TLS)

La section 2.1 de ce document définit les règles de correspondance obligatoires pour les données des associations de certificats TLSA et les certificats reçus du serveur TLS.

La session TLS qui doit être établie DOIT être pour le numéro de port et le nom de transport spécifiques qui ont été donnés dans la requête TLSA.

Certaines spécifications pour les applications qui s'exécutent sur TLS, telles que [RFC2818] pour HTTP, exigent que le certificat du serveur ait un nom de domaine qui correspond au nom d'hôte attendu par le client. Certaines spécifications, telles que [RFC6125], détaillent comment faire correspondre l'identité donnée dans un certificat PKIX avec celles attendues par l'utilisateur.

Si un enregistrement TLSA a une utilisation de certificat 2, le serveur TLS correspondant DEVRAIT envoyer le certificat référencé tout comme il envoie actuellement des certificats intermédiaires.

4.1. Associations de certificats utilisables (Usable Certificate Associations)

Une implémentation de ce protocole effectue une requête DNS pour les enregistrements TLSA, valide ces enregistrements en utilisant DNSSEC, et utilise les enregistrements TLSA résultants et l'état de validation pour modifier ses réponses au serveur TLS.

La détermination de l'utilisation d'un RRSet TLSA DOIT être basée sur l'état de validation DNSSEC (tel que défini dans [RFC4033]).

• Un RRSet TLSA dont l'état de validation DNSSEC est sécurisé DOIT être utilisé comme association de certificat pour TLS sauf si une politique locale interdirait l'utilisation de l'association de certificat spécifique dans le RRSet TLSA sécurisé.

• Si l'état de validation DNSSEC sur la réponse à la demande du RRSet TLSA est faux, cela DOIT empêcher le démarrage de TLS ou, si la négociation TLS est déjà en cours, DOIT provoquer l'interruption de la connexion.

• Un RRSet TLSA dont l'état de validation DNSSEC est indéterminé ou non sécurisé ne peut pas être utilisé pour TLS et DOIT être considéré comme inutilisable.

Les clients qui valident eux-mêmes les signatures DNSSEC DOIVENT utiliser les procédures de validation DNSSEC standard. Les clients qui comptent sur une autre entité pour effectuer la validation de signature DNSSEC DOIVENT utiliser un mécanisme sécurisé entre eux et le validateur. Des exemples de transports sécurisés vers d'autres hôtes incluent TSIG [RFC2845], SIG(0) [RFC2931] et IPsec [RFC6071]. Notez qu'il ne suffit pas d'utiliser un transport sécurisé vers un résolveur DNS qui n'effectue pas de validation de signature DNSSEC. Voir la section 8.3 pour plus de considérations de sécurité liées aux validateurs externes.

Si une association de certificat contient une utilisation de certificat, un sélecteur ou un type de correspondance qui n'est pas compris par le client TLS, cette association de certificat DOIT être considérée comme inutilisable. Si les données de comparaison d'un certificat sont mal formées, l'association de certificat DOIT être considérée comme inutilisable.

Si une association de certificat contient un type de correspondance ou des données d'association de certificat qui utilisent un algorithme cryptographique considéré comme trop faible pour la politique du client TLS, l'association de certificat DOIT être considérée comme inutilisable.

Si une application reçoit zéro association de certificat utilisable d'une requête DNS ou de son cache, elle traite TLS de manière normale sans aucune entrée des enregistrements TLSA. Si une application reçoit une ou plusieurs associations de certificats utilisables, elle tente de faire correspondre chaque association de certificat avec le certificat d'entité finale du serveur TLS jusqu'à ce qu'une correspondance réussie soit trouvée. Pendant la poignée de main TLS, si aucune des associations de certificats ne correspond au certificat donné par le serveur TLS, le client TLS DOIT abandonner la poignée de main.

Un attaquant capable de détourner un utilisateur vers un serveur sous son contrôle est également susceptible de pouvoir bloquer les requêtes DNS de l'utilisateur ou les réponses DNS envoyées à l'utilisateur. Ainsi, pour obtenir un avantage de sécurité de l'utilisation de certificat 0 ou 1, une application qui envoie une demande d'enregistrements TLSA doit obtenir soit une réponse signée valide contenant des enregistrements TLSA, soit une vérification que le domaine est non sécurisé ou indéterminé. Si une demande d'enregistrement TLSA ne répond pas à l'un de ces deux critères mais que l'application continue quand même avec la poignée de main TLS, l'application n'a obtenu aucun avantage de TLSA et NE DEVRAIT PAS faire d'indication interne ou externe que TLSA a été appliqué. Si une application a un paramètre de configuration qui a activé l'utilisation de TLSA, ou a une indication que TLSA est utilisé (qu'il soit configurable ou non), cette application NE DOIT PAS démarrer une connexion TLS ou DOIT abandonner une poignée de main TLS si les deux critères ci-dessus ne sont pas remplis.

L'application peut effectuer la recherche TLSA avant de lancer la poignée de main TLS, ou le faire pendant la poignée de main TLS : le choix appartient au client.