1. Introduction
1.1. Contexte et motivation (Background and Motivation)
Les applications qui communiquent sur Internet ont souvent besoin d'empêcher l'écoute clandestine, la falsification ou la contrefaçon de leurs communications. Le protocole Transport Layer Security (TLS) fournit ce type de sécurité des communications sur Internet, en utilisant le chiffrement de canal.
Les propriétés de sécurité des systèmes de chiffrement dépendent fortement des clés qu'ils utilisent. Si les clés secrètes sont révélées, ou si les clés publiques peuvent être remplacées par de fausses clés (c'est-à-dire une clé ne correspondant pas à l'entité identifiée dans le certificat), ces systèmes offrent peu ou pas de sécurité.
TLS utilise des certificats pour lier les clés et les noms. Un certificat combine une clé publiée avec d'autres informations telles que le nom du service qui utilise la clé, et cette combinaison est signée numériquement par une autre clé. Avoir une clé dans un certificat n'est utile que si l'on fait confiance à l'autre clé qui a signé le certificat. Si cette autre clé a elle-même été révélée ou substituée, alors sa signature ne vaut rien pour prouver quoi que ce soit sur la première clé.
Sur Internet, ce problème a été résolu pendant des années par des entités appelées "Autorités de Certification" (CA). Les CA protègent vigoureusement leur clé secrète, tout en fournissant leur clé publique aux éditeurs de logiciels qui construisent des clients TLS. Elles signent ensuite des certificats et les fournissent aux serveurs TLS. Les logiciels clients TLS utilisent un ensemble de ces clés CA comme "ancres de confiance" pour valider les signatures sur les certificats que le client reçoit des serveurs TLS. Les logiciels clients permettent généralement à n'importe quelle CA de signer utilement n'importe quel autre certificat.
Le modèle de CA publique sur lequel TLS s'est appuyé est fondamentalement vulnérable car il permet à n'importe laquelle de ces CA d'émettre un certificat pour n'importe quel nom de domaine. Une seule CA de confiance qui trahit sa confiance, soit volontairement, soit en fournissant une protection moins que rigoureuse de ses secrets et capacités, peut compromettre la sécurité offerte par tous les certificats employés avec TLS. Ce problème survient parce qu'une CA compromise peut émettre un certificat de remplacement contenant une fausse clé. Les expériences récentes de compromissions de CA ou de leurs partenaires de confiance ont conduit à des problèmes de sécurité très graves, tels que les gouvernements de plusieurs pays tentant d'intercepter et/ou de subvertir des sites Web majeurs protégés par TLS et approuvés par des millions d'utilisateurs.
Les extensions de sécurité DNS (DNSSEC) fournissent un modèle similaire qui implique des clés de confiance signant les informations pour des clés non fiables. Cependant, DNSSEC apporte trois améliorations significatives. Les clés sont liées aux noms dans le système de noms de domaine (DNS), plutôt qu'à des chaînes d'identification arbitraires ; ceci est plus pratique pour les protocoles Internet. Les clés signées pour tout domaine sont accessibles en ligne via une requête simple utilisant le protocole DNSSEC standard, donc il n'y a aucun problème de distribution des clés signées. Plus important encore, les clés associées à un nom de domaine ne peuvent être signées que par une clé associée au parent de ce nom de domaine ; par exemple, les clés pour "example.com" ne peuvent être signées que par les clés pour "com", et les clés pour "com" ne peuvent être signées que par la racine DNS. Cela empêche un signataire non fiable de compromettre les clés de quiconque sauf celles de ses propres sous-domaines. Comme TLS, DNSSEC repose sur des clés publiques intégrées dans le logiciel client DNSSEC, mais ces clés proviennent uniquement d'un seul domaine racine plutôt que d'une multiplicité de CA.
L'authentification basée sur DNS des entités nommées (DANE) offre l'option d'utiliser l'infrastructure DNSSEC pour stocker et signer les clés et certificats utilisés par TLS. DANE est envisagé comme une base préférable pour lier les clés publiques aux noms DNS, car les entités qui se portent garantes de la liaison des données de clé publique aux noms DNS sont les mêmes entités responsables de la gestion des noms DNS en question. Bien que le système résultant présente encore des vulnérabilités de sécurité résiduelles, il restreint la portée des assertions qui peuvent être faites par toute entité, conformément à la portée de dénomination imposée par la hiérarchie DNS. En conséquence, DANE incarne le "principe de moindre privilège" de sécurité qui fait défaut dans le modèle actuel de CA publiques.
1.2. Sécurisation de l'association d'un nom de domaine avec le certificat d'un serveur (Securing the Association of a Domain Name with a Server's Certificate)
Un client TLS commence une connexion en échangeant des messages avec un serveur TLS. Pour de nombreux protocoles d'application, il recherche le nom du serveur en utilisant le DNS pour obtenir une adresse de protocole Internet (IP) associée au nom. Il commence ensuite une connexion vers un port particulier à cette adresse et y envoie un message initial. Cependant, le client ne sait pas encore si un adversaire intercepte et/ou modifie sa communication avant qu'elle n'atteigne le serveur TLS. Il ne sait même pas si le véritable serveur TLS associé à ce nom de domaine a déjà reçu ses messages initiaux.
La première réponse du serveur en TLS peut contenir un certificat. Pour que le client TLS authentifie qu'il communique avec le serveur TLS attendu, le client doit valider que ce certificat est associé au nom de domaine utilisé par le client pour accéder au serveur. Actuellement, le client doit extraire le nom de domaine du certificat et doit valider avec succès le certificat, y compris l'enchaînement vers une ancre de confiance.
Il existe une manière différente d'authentifier l'association du certificat du serveur avec le nom de domaine prévu sans faire confiance à une CA externe. Étant donné que l'administrateur DNS d'un nom de domaine est autorisé à fournir des informations d'identification sur la zone, il est logique de permettre à cet administrateur de créer également une liaison faisant autorité entre le nom de domaine et un certificat qui pourrait être utilisé par un hôte de ce nom de domaine. Le moyen le plus simple de le faire est d'utiliser le DNS, en sécurisant la liaison avec DNSSEC.
Il existe de nombreux cas d'utilisation pour une telle fonctionnalité. [RFC6394] répertorie ceux auxquels le type RR DNS de ce document s'applique. [RFC6394] répertorie également de nombreuses exigences, dont la plupart sont censées être satisfaites par ce document. La section 5 couvre en détail l'applicabilité de ce document aux cas d'utilisation. Le protocole dans ce document peut généralement être appelé le protocole "DANE TLSA". ("TLSA" ne signifie rien ; c'est juste le nom du type RR.)
Ce document s'applique à la fois à TLS [RFC5246] et à Datagram TLS (DTLS) [RFC6347]. Pour rendre le document plus lisible, il ne parle principalement que de "TLS", mais dans tous les cas, cela signifie "TLS ou DTLS". Bien que les références dans ce paragraphe concernent TLS et DTLS version 1.2, le protocole DANE TLSA peut également être utilisé avec des versions antérieures de TLS et DTLS.
Ce document ne concerne que l'association sécurisée de certificats pour TLS et DTLS avec des noms d'hôte ; la récupération de certificats depuis DNS pour d'autres protocoles est traitée dans d'autres documents. Par exemple, les clés pour IPsec sont couvertes dans [RFC4025], et les clés pour Secure SHell (SSH) sont couvertes dans [RFC4255].
1.3. Méthode de sécurisation des associations de certificats (Method for Securing Certificate Associations)
Une association de certificat est formée à partir d'une information identifiant un certificat et le nom de domaine où l'application serveur s'exécute. La combinaison d'une ancre de confiance et d'un nom de domaine peut également être une association de certificat.
Une requête DNS peut retourner plusieurs associations de certificats, comme dans le cas d'un serveur qui passe d'un certificat à un autre (décrit plus en détail dans l'annexe A.4).
Ce document s'applique uniquement aux certificats PKIX [RFC5280], pas aux certificats d'autres formats.
Ce document définit une méthode sécurisée pour associer le certificat obtenu du serveur TLS avec un nom de domaine en utilisant DNS ; les informations DNS doivent être protégées par DNSSEC. Parce que l'association de certificat a été récupérée sur la base d'une requête DNS, le nom de domaine dans la requête est par définition associé au certificat. Notez que ce document ne couvre pas comment associer des certificats avec des noms de domaine pour les protocoles d'application qui dépendent de SRV, NAPTR et des enregistrements de ressources DNS similaires. Il est prévu que de futurs documents couvriront les méthodes pour créer ces associations, et ces documents peuvent ou non avoir besoin de mettre à jour celui-ci.
DNSSEC, qui est défini dans [RFC4033], [RFC4034] et [RFC4035], utilise des clés cryptographiques et des signatures numériques pour fournir l'authentification des données DNS. Les informations récupérées depuis le DNS et validées en utilisant DNSSEC sont ainsi prouvées être les données faisant autorité. La signature DNSSEC doit être validée sur toutes les réponses qui utilisent DNSSEC afin d'assurer la preuve d'origine des données.
Ce document ne spécifie pas comment la validation DNSSEC se produit car il existe de nombreuses propositions différentes sur la manière dont un client pourrait obtenir des résultats DNSSEC validés, comme depuis un résolveur conscient DNSSEC codé dans l'application, depuis un résolveur DNSSEC de confiance sur la machine sur laquelle l'application s'exécute, ou depuis un résolveur DNSSEC de confiance avec lequel l'application communique sur un canal ou réseau authentifié et protégé en intégrité. Ceci est décrit plus en détail dans la section 7 de [RFC4033].
Ce document ne concerne que l'obtention sécurisée des informations DNS pour l'association de certificat en utilisant DNSSEC ; les autres mécanismes DNS sécurisés sont hors de portée.
1.4. Terminologie (Terminology)
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans RFC 2119 [RFC2119].
Ce document utilise également la terminologie standard PKIX, DNSSEC, TLS et DNS. Voir [RFC5280], [RFC4033], [RFC5246] et STD 13 [RFC1034] [RFC1035], respectivement, pour ces termes. De plus, les termes liés aux services d'application protégés par TLS et aux noms DNS sont tirés de [RFC6125].