Résumé

  • Une session DNS chiffrée et authentifiée constitue une preuve bornée du transport ; elle ne prouve ni ce que le résolveur conserve, ni ce qu’il corrèle, partage, filtre ou transmet en amont.
  • La déclaration de confidentialité d’un opérateur récursif proposée par le RFC 8932 rend ces choix comparables, à condition de ne pas la confondre avec les preuves datées du traitement, du stockage, des accès et des divulgations.

Le geste paraît décisif. Un utilisateur choisit un résolveur chiffré, son appareil établit une connexion TLS, HTTPS ou QUIC, et le réseau local ne peut plus lire ses questions DNS aussi facilement. Le client authentifie le service. Sur un accès Wi-Fi ouvert comme sur le réseau d’un opérateur, cette protection retire à des observateurs intermédiaires une visibilité considérable.

Puis la connexion chiffrée arrive à destination.

Le résolveur déchiffre la requête pour consulter son cache, valider une réponse ou interroger d’autres serveurs. Son opérateur peut, en principe, voir le nom demandé et les identifiants de transport associés. Il choisit les champs journalisés, la durée de conservation, les personnes autorisées, les rapprochements entre sessions, les réponses modifiées et les données envoyées plus loin. Le cadenas n’a jamais promis de répondre à ces questions.

C’est la frontière décisive du RFC 8932, Recommendations for DNS Privacy Service Operators. Publié en octobre 2020 comme BCP 232, le texte est signé par Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij et Allison Mankin. Le profil IETF de Dickinson recense huit RFC, dont le RFC 8932 et le RFC 9250 sur DNS over QUIC, et indique qu’elle préside le Privacy Enhancements and Assessments Research Group. RIPE Labs la présente comme cofondatrice de Sinodun IT. Cette attribution atteste un travail continu et collectif ; elle ne transforme pas Dickinson en inventrice unique du DNS chiffré ni en opératrice des services évoqués.

Le RFC 8932 formule des recommandations opérationnelles et introduit un cadre de publication : la Recursive operator Privacy Statement, ou RPS. Il ne dicte pas une politique universelle et ne délivre aucune conformité automatique. Il propose un ordre commun dans lequel les opérateurs peuvent exposer leurs engagements et leurs pratiques, afin que le lecteur distingue ce qui est déclaré de ce qui est mesurable.

La première pièce du dossier concerne le transport entre le client et le résolveur. Elle peut consigner l’adresse du service, le nom d’authentification, le protocole, le résultat du certificat, la version de TLS ou de QUIC, le bourrage, la disponibilité et le comportement de repli. Le RFC 8310 encadre les profils d’usage de DNS over TLS ; le RFC 8484 définit DNS over HTTPS ; le RFC 9250 ajoute les connexions QUIC dédiées. Ces mécanismes protègent un segment précis. Ils n’ordonnent pas à l’opérateur d’oublier la question une fois déchiffrée.

Ils ne remplacent pas davantage DNSSEC. Le RFC 8932 insiste sur l’indépendance des deux protections. Pour un client qui ne valide pas lui-même DNSSEC, un transport authentifié et chiffré ne prouve pas que le résolveur a validé les données reçues. Le client peut seulement faire confiance au bit AD posé par le service. Un certificat TLS répond à l’identité de l’extrémité du transport ; il n’est pas la preuve de validation de la réponse DNS.

La deuxième pièce décrit le traitement au sein du service. Quel mode de validation a fonctionné ? Une règle de sécurité a-t-elle modifié la réponse ? Quel cache a répondu ? Une exception a-t-elle été activée ? Plusieurs connexions ont-elles été réunies grâce à l’adresse IP, à la reprise de session, à des en-têtes HTTP, à une empreinte TLS ou à un motif de requêtes ? Le RFC 9076 souligne que du trafic DNS chiffré peut parfois être corrélé avec les questions en clair qui sortent du résolveur récursif.

Le choix d’un résolveur chiffré fixe donc plus clairement le destinataire de confiance, mais peut aussi donner au même opérateur un fil continu lorsque l’utilisateur passe d’un réseau à l’autre. Ce n’est pas un argument contre le chiffrement. C’est la raison pour laquelle la protection contre l’observation sur le trajet et la limitation de la corrélation au point d’arrivée doivent rester deux engagements séparés.

Le filtrage appartient lui aussi au traitement. Le RFC 8932 demande à l’opérateur d’indiquer si les réponses sont retirées ou modifiées pour la sécurité du réseau, en exécution d’une obligation juridique, par politique volontaire de réduction du risque, pour une raison commerciale ou pour tout autre motif. Il demande également l’origine et la gestion des listes. Un service peut donc offrir un canal confidentiel tout en livrant une réponse transformée. L’étiquette « DNS sécurisé » ne suffit pas à décrire les deux décisions.

La troisième pièce porte sur le stockage et les accès. Le RFC recommande de réduire la conservation au minimum, voire de l’éviter. Lorsque des données restent nécessaires, il recommande leur chiffrement et, lorsque c’est possible, leur agrégation, pseudonymisation ou anonymisation. La durée des journaux doit répondre aux seuls besoins de fonctionnement et aux exigences réglementaires applicables ; l’accès doit être limité aux personnes qui en ont besoin pour leur mission.

Chaque recommandation appelle toutefois une preuve d’exécution distincte. Une politique annonçant sept jours établit un engagement ; le résultat d’une purge montre qu’un lot a effectivement été supprimé. Une matrice de rôles décrit qui devrait accéder aux données ; un journal d’accès indique qui les a ouvertes. Le chiffrement du disque ne prouve pas l’absence d’export. Et la pseudonymisation n’est pas automatiquement de l’anonymisation : un identifiant stable conserve la possibilité de relier des observations, parfois de retrouver l’identité si la méthode ou la table de correspondance est disponible.

La quatrième pièce suit les données envoyées hors du résolveur. Pour résoudre un nom, le service interroge d’autres résolveurs ou des serveurs faisant autorité. Le RFC 8932 recommande la minimisation du QNAME afin que chaque étape ne reçoive que la partie du nom nécessaire ; le RFC 9156 en actualise les règles. Il recommande aussi d’éviter EDNS Client Subnet, ou à défaut d’utiliser le préfixe le plus court compatible avec le service et de publier la politique réellement appliquée.

Une sonde indépendante peut vérifier, depuis un point donné et à un instant donné, qu’un nom a été minimisé ou qu’aucun ECS n’a été observé. C’est une preuve utile. Elle ne couvre pas toutes les destinations, tous les relais et toutes les branches de configuration. Elle ne voit pas non plus un transfert ultérieur d’une copie de journal. La première liaison peut être impeccablement chiffrée alors que la seconde laisse échapper une information plus détaillée que prévu.

Voilà pourquoi la RPS doit dépasser la formule « nous respectons votre vie privée ». Sa partie politique décrit le statut des adresses IP, les données collectées et conservées, les partages, ventes ou locations, les méthodes de réduction, les exceptions, les entités associées et le financement, la corrélation avec d’autres informations et le filtrage. Sa partie pratique expose les transports et méthodes d’authentification disponibles, les capacités en amont, les écarts temporaires ou permanents, le support et les informations de traitement pertinentes.

La déclaration devient utile lorsqu’elle sert d’index vers les preuves. La promesse de minimiser les QNAME peut renvoyer à une configuration et à un test externe. Une durée de conservation peut renvoyer à une règle de cycle de vie et à des résultats de suppression. Une limite d’accès peut renvoyer à la politique de rôles et à des événements audités. Un partage peut nommer le destinataire, le but, les champs, le fondement et l’échéance. Des rapports de transparence et des audits tiers, avec un périmètre explicite, peuvent examiner une partie supplémentaire du système.

Mais un index ne vaut pas exécution. Un audit a une période, un échantillon et des exclusions. Une mesure externe a un lieu d’observation. Un rapport dépend de l’accès de son auteur. Une RPS peut prendre du retard sur la configuration. Admettre ces limites ne rend pas la confidentialité invérifiable ; cela oblige à choisir un témoin adapté pour chaque affirmation et à dater sa portée.

L’apport durable de Dickinson et de ses coauteurs est d’avoir donné un vocabulaire public à ces décisions cachées. La question ne s’arrête plus à « le tuyau est-il chiffré ? ». Elle devient : qui décide après l’arrivée de la requête, quelles traces permettent de contrôler cette décision, et à quel moment la promesse doit-elle être vérifiée de nouveau ?

Sources