Resumen

  • RFC 9540 define el parámetro vacío ohttp para registros SVCB y HTTPS, una pasarela en /.well-known/ohttp-gateway y la descarga de su configuración de claves.
  • El estándar no descubre el relé ni convierte el anuncio, el certificado, la clave o una respuesta exitosa en una prueba conjunta de privacidad.
  • Una clave, redirección o ruta dohpath asignada sólo a un cliente puede restaurar la vinculabilidad; la coherencia necesita su propia evidencia.

La anomalía no apareció en los errores. Apareció en los éxitos. Dos teléfonos descubrieron el mismo resolvedor, validaron el mismo nombre y recibieron respuestas correctas. Uno usó una clave pública compartida por miles de clientes. El otro recibió una configuración que nadie más había observado.

Ambos intercambios estaban cifrados. Sólo uno pertenecía a una multitud.

La RFC 9540, publicada en febrero de 2024, merece atención precisamente porque no esconde este problema. Lleva el descubrimiento de Oblivious HTTP a los registros Service Binding y estandariza el acceso a la pasarela y a sus claves. Después explica cómo ese mismo trayecto puede usarse para apuntar a una persona. La lección no es que OHTTP carezca de valor, sino que cada salto conserva una autoridad distinta y demuestra una cosa distinta.

El parámetro no contiene datos, pero sí una decisión

ohttp debe tener valor vacío tanto en texto como en el formato de red. Su presencia declara que el servicio descrito puede actuar como objetivo OHTTP mediante una pasarela asociada. Si el publicador lo incluye en mandatory, los clientes que no lo entiendan deben descartar el registro. Si no es obligatorio, anuncia una opción, no una exigencia. Varios registros pueden ofrecer alternativas.

Ese resultado sólo acredita que una fuente de descubrimiento anunció la capacidad bajo unas reglas de selección. No dice que el cliente la usó. No autentica el comportamiento de la pasarela. No garantiza que otro cliente recibió el mismo material. Si la respuesta DNS viaja en claro y no está protegida por DNSSEC, un intermediario puede eliminar la indicación y degradar el acceso. Consultar la ruta conocida o combinar DNS cifrado con DNSSEC ayuda, pero sigue sin anticipar la conducta de las siguientes capas.

Para una organización, el registro mínimo debe incluir la respuesta original, el resolvedor y el punto de observación, el TTL, la validación DNSSEC, el transporte, la lista mandatory, la alternativa elegida y el motivo. Convertir todo ello en ohttp=true borra la parte más importante: quién habló y qué elección provocó.

El relé no viene dentro del descubrimiento

OHTTP reparte información entre un relé, una pasarela y un objetivo. El relé conoce la identidad de red del cliente y la pasarela de destino, pero no debería poder abrir el mensaje. La pasarela abre la envoltura y entrega la petición al objetivo sin recibir directamente la dirección del cliente. La separación limita lo que una sola función puede saber.

RFC 9540 descubre el objetivo y la pasarela. La búsqueda del relé queda expresamente fuera de alcance. El modelo presupone que el cliente ya confía en un relé capaz de alcanzar la pasarela o de comprobar cuáles puede alcanzar.

Por eso una implementación conforme puede seguir teniendo un hueco de gobierno. Hay que saber quién seleccionó el relé, qué conserva, bajo qué jurisdicción opera, cómo resuelve abusos y si comparte control económico o técnico con la pasarela. Una etiqueta de interfaz que diga “OHTTP activo” no responde a ninguna de esas preguntas.

La misma dirección conocida debe producir dos recorridos independientes

El cliente localiza la pasarela en /.well-known/ohttp-gateway, en el mismo host que el objetivo. El servidor puede responder con una redirección. Sin embargo, el cliente no debe entregar al relé la dirección redirigida que recibió durante la descarga de claves.

La razón es concreta: una pasarela podría insertar un identificador exclusivo en la URL para ese cliente y reconocerlo cuando el relé lo reutilice. El relé debe empezar de nuevo en la ruta conocida y seguir sus propias redirecciones. Puede memorizar una ruta común a todos, no heredar un rastro personal.

La telemetría correcta conserva ambas secuencias. Una pertenece a la obtención de configuración del cliente; la otra, al envío encapsulado del relé. Si el sistema sólo guarda la URL final, pierde la comparación capaz de demostrar que no hubo direccionamiento individual.

La privacidad puede debilitarse antes de la primera petición protegida

Para cifrar, el cliente necesita una configuración de clave. La obtiene con un GET a la pasarela y la cabecera Accept: application/ohttp-keys. Una solicitud directa revela a la pasarela la dirección IP desde la que se prepara el uso de OHTTP. Quizá sea aceptable para separar consultas de un abonado ya conocido, pero no para ocultar ubicación ni cuando la dirección permite elegir una clave individual.

Un proxy puede ocultar ese dato. Aun así, debe examinarse el objeto devuelto. Una configuración puede estar bien formada, usar algoritmos aceptables y ser exclusiva. Como las peticiones pueden vincularse por la configuración empleada, una clave distinta para cada persona crea identificadores criptográficamente válidos.

RFC 9540 aconseja comparar la clave mediante alguna técnica de coherencia, por ejemplo a través de un proxy compartido. Si aparece una configuración dirigida, el cliente puede dejar de usar la pasarela y denunciarla. Para que esa recomendación sea operativa, el propietario del servicio debe definir grupo de comparación, duración, rotación, observadores independientes y umbral de alerta. La validez responde «¿puedo cifrar?». La coherencia responde «¿me dieron lo mismo que a otros?».

dohpath es otra clave de clasificación

En DoH oblivious, una ruta exclusiva puede identificar a un cliente aunque la clave sea común. El estándar propone limitarse a una ruta conocida, como /dns-query{?dns}, o verificar cualquier valor arbitrario con una fuente distinta. Se pueden muestrear las comprobaciones según la amenaza y la capacidad, pero entonces la conclusión también debe limitarse a la muestra.

DDR y DNR tampoco son intercambiables. DDR conserva sus comprobaciones de certificado para el resolvedor descubierto. DNR puede entregar parámetros mediante DHCP o anuncios de router y parte de otra autoridad de designación. Ninguno evita por sí mismo una ruta única. El certificado contesta quién controla una identidad de endpoint; no si ese controlador clasificó al cliente.

El tablero necesita una escalera de recibos

Conviene separar nueve hechos: la publicación de ohttp; la interpretación de su carácter obligatorio; la aceptación de la designación DDR o DNR; la identidad del endpoint; la recepción de una clave utilizable; la coherencia de clave, ruta y redirección; la aceptación del relé; el éxito de la transacción; y la propiedad de privacidad que realmente respalda la evidencia.

No forman una cadena automática de aprobación. Una respuesta correcta no legitima retroactivamente la designación. Un certificado no demuestra una configuración común. Una configuración común no prueba que relé y pasarela sean independientes. La privacidad es una conclusión acotada que combina observaciones, no un bit del protocolo.

La arquitectura gana credibilidad cuando conserva estas fronteras. Permite localizar el fallo y comunicar con precisión si el sistema ofrece disponibilidad, separación de consultas o una protección más amplia de identidad. El anuncio inicia la investigación; nunca debe sustituirla.

Fuentes