Summary

  • Les filtres de capacité, de localisation, de confiance et de disponibilité peuvent révéler la politique de sélection d’une organisation avant tout échange avec l’agent finalement retenu.
  • draft-iannone-dawn-privacy-considerations-00 décrit utilement surveillance, compromission des données stockées, corrélation et identification, mais ce projet individuel reste inachevé : plusieurs menaces, la comparaison DNS, le rapport entre vie privée et auditabilité ainsi que le questionnaire RFC 6973 sont encore TBD.
  • Daniel Kade propose un budget d’exposition de la sélection fixant granularité des requêtes, taille minimale du groupe de candidats, durée de corrélation, séparation des rôles, amorçage, audience des réponses et conservation. Il s’agit d’une recommandation éditoriale, non d’une exigence DAWN ou IETF.

La requête est déjà une décision condensée

On présente volontiers la découverte comme une opération technique sans conséquence politique. Un client décrit un besoin, un annuaire renvoie des entités compatibles, puis une couche distincte choisit, autorise et orchestre. Cette séparation fonctionnelle est utile. Elle devient trompeuse dès qu’on l’interprète comme une séparation de l’information.

Dans les documents DAWN, une entité découvrable peut être un agent, une charge de travail ou une autre ressource nommée. Ses propriétés peuvent couvrir fonction, capacité, protocole, propriétaire, emplacement, juridiction ou indicateur de confiance. Une fiche de capacité structurée doit permettre à une machine de comparer des entités au-delà des frontières administratives. Plus cette description est exploitable, plus la requête qui la filtre ressemble à la politique interne du demandeur.

Une demande générale — « trouver un service de traduction » — révèle peu. L’ajout d’une paire linguistique, d’une contrainte de données médicales, d’une attestation particulière, d’un hébergement européen et d’une disponibilité immédiate peut désigner un dossier unique. La succession des essais est parfois plus éloquente que chaque essai : retirer la latence mais conserver la juridiction montre quelle règle est impérative; élargir la zone après un résultat vide révèle le compromis acceptable.

Le projet sur les exigences DAWN met les mécanismes et politiques de sélection hors périmètre. Il ne spécifie d’ailleurs aucune solution concrète de découverte. Or un service qui observe les attributs demandés, l’ordre des assouplissements, le nombre de réponses et le moment de la recherche peut reconstituer cette politique sans jamais voir l’acte final de sélection.

La frontière pertinente ne se réduit donc pas au texte chiffré. Elle relie l’identité du demandeur, la précision du besoin, l’ensemble des candidats, les attributs retournés et la chronologie. Une requête confidentielle peut rester politiquement transparente pour celui qui maîtrise ces jointures.

Un brouillon honnêtement incomplet

À la date de recherche, draft-iannone-dawn-privacy-considerations-00 était un Internet-Draft individuel actif, daté du 22 mai 2026. Datatracker ne lui attribuait ni flux RFC, ni Area Director responsable, ni téléconférence. La page rappelle qu’un dépôt individuel n’est pas approuvé par l’IETF. Il faut conserver cette limite à chaque fois que le texte est cité.

La révision 00 ne prétend pas être achevée. Intrusion, attribution erronée, usage secondaire, divulgation et exclusion portent encore la mention TBD. La comparaison avec la protection de la vie privée dans le DNS et la section « Privacy vs Auditability » sont elles aussi vides. Les réponses au questionnaire de la RFC 6973 restent à ajouter, des catégories de mitigation propres à DAWN sont promises pour plus tard, et les considérations de sécurité sont TBD.

Ce qui est rédigé suffit néanmoins à poser un problème sérieux. Le projet explique qu’une infrastructure de découverte peut devenir un point de surveillance : qui cherche quelle capacité, quels intérêts organisationnels apparaissent, quels rythmes de charge ou comportements opérationnels se répètent. Les journaux de requêtes et historiques d’interaction peuvent exposer des processus internes. La répétition relie les recherches; les noms d’organisation, la propriété d’infrastructure, l’identité d’un opérateur ou une combinaison rare de capacités peuvent identifier une entité.

Le texte évoque la récupération privée d’information, ou PIR, pour cacher au serveur l’élément récupéré, tout en demandant d’étudier son passage à l’échelle. Ce n’est ni un choix de protocole ni une preuve de déploiement. Même une PIR efficace ne fixe pas la finesse admissible du vocabulaire, la taille révélatrice d’une réponse, les corrélations temporelles ou les fuites du chemin d’amorçage.

Les précédents IETF protègent des jointures différentes

La RFC 6973 oblige à examiner séparément surveillance, données stockées, corrélation, identification, usage secondaire, divulgation et exclusion. La RFC 7258 ajoute que l’observation massive des contenus ou des caractéristiques externes constitue une attaque, indépendamment du motif invoqué. Ces textes empêchent de réduire la vie privée à la seule confidentialité du canal.

La minimisation de QNAME de la RFC 9156 fournit une analogie précise. Le résolveur n’envoie pas systématiquement le nom complet à chaque serveur faisant autorité; il ne révèle que la partie nécessaire à l’étape concernée. Pour DAWN, cela signifie qu’un client ne devrait pas transmettre d’emblée son profil de capacité complet si une question plus grossière permet de conserver un ensemble crédible de candidats.

La RFC 9230 sépare le proxy Oblivious DoH de la cible : le premier connaît la connexion du client sans lire la question, la seconde lit la question sans connaître l’adresse du client. La RFC 9458 transpose cette partition à HTTP et avertit que taille, calendrier, identifiants de clé, connexions et traitement différentiel peuvent réduire l’ensemble d’anonymat. Le chiffrement dépend d’une architecture de rôles et d’une hypothèse de non-collusion.

La RFC 9540 montre que la fuite peut précéder la requête protégée. Il faut découvrir la passerelle et obtenir sa configuration de clé. Une récupération directe expose l’adresse IP; un chemin, une redirection ou une clé propre au client peut restaurer le suivi. L’amorçage fait partie du modèle de confidentialité.

La RFC 9576 distingue, pour Privacy Pass, contextes d’émission, d’attestation et d’utilisation. La RFC 9614 généralise cette partition comme séparation du « qui » et du « quoi », tout en précisant qu’elle n’est pas une panacée. Ces mécanismes ne constituent pas une solution DAWN prête à l’emploi. Ils montrent pourquoi l’expression « découverte chiffrée » est trop pauvre : elle ne dit rien sur la minimisation, la taille du groupe, la combinaison des rôles, la répétition ni la conservation.

Une réponse unique est déjà une révélation

La confidentialité doit couvrir le résultat. Une requête qui ne renvoie qu’un agent annonce presque le futur interlocuteur. Deux réponses peuvent être départagées par une observation réseau ultérieure. Une longue liste assortie de propriétaires, d’emplacements, d’horaires et d’indicateurs de confiance révèle, à l’inverse, des informations sensibles sur des opérateurs qui ignorent peut-être avoir été évalués.

Le projet d’exigences demande que les entités contrôlent ce qui est public ou restreint et que la découverte n’expose rien au-delà de ce qui est nécessaire pour décider si une interaction convient. Le mot « nécessaire » doit devenir mesurable. Il dépend de la requête en plusieurs étapes, du cache, de l’anonymat du demandeur, de l’audience des attributs et de la capacité d’une équipe de sécurité à rouvrir les journaux.

Un seuil de dix candidats n’est pas une garantie universelle : dix agents contrôlés par le même opérateur peuvent offrir moins de diversité que trois agents indépendants. Une combinaison rare peut identifier le demandeur malgré cinquante résultats. Mais un plancher oblige à décider ce qui se passe lorsque la réponse isole une entité : élargir, différer, ajouter du bruit ou refuser. Sans règle, l’index choisit silencieusement la quantité d’intention à publier.

Le budget d’exposition de la sélection

Une organisation devrait exiger avant déploiement un budget d’exposition de la sélection. Ce budget n’est pas un journal central de requêtes. Il définit les limites observables et les conditions d’exception sans stocker le détail du travail recherché.

Il doit indiquer les classes d’attributs autorisées et leur granularité maximale; un plancher pour l’ensemble de candidats ou l’ensemble d’anonymat; la réponse prévue lorsque ce plancher échoue; la durée pendant laquelle des demandes successives restent corrélables; les règles de regroupement, de temporisation, de rotation ou de bourrage; et l’identité du rôle qui voit le demandeur, l’intention en clair, les candidats et les attributs rendus.

Il doit aussi documenter les hypothèses de non-collusion, la découverte de l’annuaire ou des clés, la séparation entre résultats publics, restreints et propres au demandeur, les plafonds de conservation, ainsi que l’autorité habilitée à réduire exceptionnellement l’anonymat. Toute exception doit avoir une échéance, une justification et une revue. Une voie de correction est nécessaire lorsqu’un attribut obsolète ou excessif a modifié les résultats.

La preuve n’exige pas de reproduire la surveillance. Des bandes agrégées de taille de résultat, des taux de refus, des catégories d’attributs, des comptes d’exception et des contrôles de conservation peuvent être publiés sans termes de recherche ni liste de candidats. Des requêtes synthétiques peuvent tester ce que voit chaque rôle. Le bon contrôle démontre qu’une limite a été appliquée sans centraliser le secret qu’elle devait protéger.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. Considérations de confidentialité DAWN, révision 00
  5. Statut Datatracker
  6. Historique des révisions
  7. Problématique DAWN, révision 02
  8. Exigences DAWN, révision 01
  9. Terminologie DAWN, révision 01
  10. RFC 6973 — Vie privée dans les protocoles Internet
  11. RFC 7258 — La surveillance massive est une attaque
  12. RFC 9156 — Minimisation de QNAME
  13. RFC 9230 — DNS sur HTTPS oblivious
  14. RFC 9458 — Oblivious HTTP
  15. RFC 9540 — Découverte de services oblivious
  16. RFC 9576 — Architecture Privacy Pass
  17. RFC 9614 — Partitionnement comme architecture de confidentialité