Summary

  • Una búsqueda de capacidades, ubicación, confianza y tiempo puede revelar la política interna del solicitante antes de que exista una selección o interacción con otro agente.
  • draft-iannone-dawn-privacy-considerations-00 identifica vigilancia, datos almacenados, correlación e identificación, pero es un Internet-Draft individual incompleto: quedan como TBD varias amenazas, la comparación con DNS, el equilibrio entre privacidad y auditoría, el cuestionario de RFC 6973 y las consideraciones de seguridad.
  • Daniel Kade propone un presupuesto de exposición de la selección: granularidad máxima, mínimo de candidatos, ventana de vinculación, separación de participantes, protección del arranque, audiencia de resultados y caducidad de datos. Es una propuesta editorial, no una regla de DAWN o del IETF.

Buscar también es declarar una preferencia

El relato habitual separa tres actos. Primero se descubre qué entidades existen. Después se selecciona una. Por último se autoriza y ejecuta una tarea. Desde el punto de vista del software son capas diferentes. Desde el punto de vista de la información, la primera puede revelar la lógica de las otras dos.

DAWN intenta describir el descubrimiento de agentes, cargas de trabajo y otras entidades nombradas a través de dominios administrativos. Las propiedades descubribles pueden abarcar función, capacidad, protocolo, organización operadora, geografía, jurisdicción e indicadores de confianza. Las tarjetas de capacidad estructuradas permiten filtrar y componer servicios sin relaciones preconfiguradas. Ese beneficio convierte la consulta en una versión comprimida de la política de selección.

“Busco traducción” deja un conjunto amplio. Añadir idioma, datos sanitarios, una forma de atestación, alojamiento europeo, un modelo determinado y una hora límite puede señalar un proyecto concreto. Las reformulaciones aportan más información: mantener la jurisdicción y relajar el coste revela qué restricción es innegociable; repetir la búsqueda justo después de una caída revela el tipo de respuesta operativa que se prepara.

El borrador de requisitos DAWN excluye expresamente los mecanismos y políticas de selección. La exclusión limita lo que el documento pretende estandarizar, pero no lo que un observador puede inferir. El índice que ve los atributos consultados, el orden de las concesiones, la cantidad de coincidencias y el horario aprende la política aunque nunca conozca qué agente fue elegido.

Por eso la unidad de privacidad no es únicamente el texto de la petición. Es la combinación de identidad, intención, conjunto candidato, detalle devuelto y tiempo. Cifrar uno de esos elementos puede ser necesario y, aun así, dejar reconstruible la decisión.

Un inventario de riesgos, no una arquitectura terminada

En la fecha de corte, draft-iannone-dawn-privacy-considerations-00 era un Internet-Draft individual activo del 22 de mayo de 2026. Datatracker no mostraba flujo RFC, Area Director responsable ni telechat y advertía que el texto no cuenta con respaldo formal del IETF. No debe presentarse como consenso, especificación adoptada ni práctica desplegada.

La revisión 00 conserva vacíos visibles. Intrusión, atribución errónea, uso secundario, divulgación y exclusión figuran como TBD. También están pendientes la comparación con la privacidad de DNS, la sección “Privacy vs Auditability”, las respuestas al cuestionario de RFC 6973, mitigaciones específicas de DAWN y las consideraciones de seguridad. La honestidad de esos huecos es parte de la evidencia.

Los párrafos terminados sí son incisivos. Una infraestructura de descubrimiento puede observar qué agentes preguntan por qué capacidades y derivar intereses organizativos, patrones de carga y conducta operativa. Los registros de consultas y los historiales de interacción pueden revelar flujos internos. La repetición permite correlacionar búsquedas; los nombres de organización, la propiedad de infraestructura, la identidad operadora y combinaciones raras de capacidades permiten identificar.

El borrador menciona la recuperación privada de información como bloque tecnológico capaz de ocultar al servidor qué registro obtiene el usuario, pero deja abierta su viabilidad a escala. PIR no es todavía una elección DAWN. Tampoco decide qué campos son demasiado finos, cuándo una respuesta resulta identificadora o qué metadatos aparecen antes de que la recuperación privada comience.

La privacidad se reparte entre participantes

La RFC 6973 obliga a estudiar por separado vigilancia, almacenamiento, correlación, identificación, reutilización y divulgación. La RFC 7258 recuerda que la monitorización masiva de contenidos o características externas es un ataque con independencia de la motivación. Ambas impiden que “usa cifrado” sea una conclusión suficiente.

La RFC 9156 ofrece una lección de minimización. Un resolutor que aplica QNAME minimisation no envía el nombre completo a cada servidor autoritativo; revela lo necesario para esa etapa. En el descubrimiento de agentes, el equivalente sería preguntar primero por una clase amplia y reservar los requisitos finos hasta que exista una razón y una audiencia apropiadas.

La RFC 9230 divide el conocimiento entre el proxy de Oblivious DoH y el objetivo. El proxy conoce la conexión, pero no la pregunta DNS en claro; el objetivo conoce la pregunta, pero no la dirección del cliente. La RFC 9458 amplía ese principio a HTTP y advierte que tamaño, tiempo, identificadores de clave, conexiones y trato diferencial reducen el anonimato. La propiedad depende de la separación de roles y de que no coludan.

La RFC 9540 localiza otra fuga: descubrir una pasarela oblivious y obtener su clave puede revelar la IP antes de la petición protegida. Rutas, redirecciones o configuraciones únicas permiten dirigir y vincular clientes. La privacidad empieza en el arranque, no en el primer paquete encapsulado.

Privacy Pass, en la RFC 9576, separa emisión, atestación y canje. La RFC 9614 denomina “partición de privacidad” a mantener separado quién es alguien de lo que hace, pero niega que la partición sea una panacea. Estos textos no constituyen una solución DAWN; sirven para enumerar las uniones que un diseño debe impedir.

El tamaño de la respuesta cambia el significado

Una respuesta con un único agente revela casi por completo el posible destino. Dos resultados pueden distinguirse mediante una observación posterior. Cien resultados no garantizan privacidad si noventa y ocho pertenecen al mismo operador o si la combinación consultada identifica al solicitante.

El borrador de requisitos dice que las entidades deben controlar qué información es pública o restringida y que el descubrimiento no debe exigir más datos de los necesarios para saber si una interacción es adecuada. Esa regla necesita una conducta para el caso límite. Cuando el filtro deja una sola coincidencia, ¿el servicio amplía, espera, agrupa, oculta campos o rechaza?

Un mínimo de candidatos no es una puntuación universal. Es una obligación de no fingir que una respuesta estrecha es neutral. También hace visible quién toma la decisión: sin política declarada, el operador del índice determina silenciosamente cuánta intención del cliente y cuánta información del agente se exponen.

Presupuestar la exposición sin guardar la consulta

Antes de desplegar un servicio, el responsable debería aprobar un presupuesto de exposición de la selección. No sería un registro central de consultas, sino un contrato operativo sobre lo que cada rol puede aprender.

El presupuesto fijaría clases de atributo y granularidad máxima; suelo de candidatos o anonimato; acción cuando ese suelo falla; ventana durante la cual se pueden relacionar búsquedas sucesivas; reglas de agrupación, demora, relleno o rotación; y una matriz de quién ve identidad del solicitante, intención en claro, lista candidata y atributos de respuesta. Las hipótesis de no colusión deben aparecer como dependencia, no esconderse en un dibujo.

También incluiría el camino para descubrir directorio, relay, pasarela y claves; audiencias públicas, restringidas y específicas del solicitante; límites de conservación de consultas y agregados; autoridad capaz de aprobar una reducción excepcional del anonimato; caducidad y revisión de esa excepción; y un canal para corregir propiedades obsoletas que alteraron el resultado.

La comprobación puede evitar la vigilancia. Se pueden publicar bandas de tamaño, tasas de rechazo, clases de atributo usadas, número de excepciones y cumplimiento de borrado sin exponer términos ni candidatos. Pruebas sintéticas pueden verificar qué observa cada participante. El objetivo es demostrar que existió un límite, no reconstruir el secreto para justificarlo.

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. Privacidad de DAWN, revisión 00
  5. Estado en Datatracker
  6. Historial de revisiones
  7. Planteamiento del problema DAWN, revisión 02
  8. Requisitos DAWN, revisión 01
  9. Terminología DAWN, revisión 01
  10. RFC 6973 — Privacidad en protocolos de Internet
  11. RFC 7258 — La vigilancia masiva es un ataque
  12. RFC 9156 — Minimización de QNAME
  13. RFC 9230 — Oblivious DNS over HTTPS
  14. RFC 9458 — Oblivious HTTP
  15. RFC 9540 — Descubrimiento de servicios oblivious
  16. RFC 9576 — Arquitectura Privacy Pass
  17. RFC 9614 — Partición como arquitectura de privacidad