Summary

  • La validación definida alrededor de RFC 9934 puede probar que la clave privada de un archivo PEM corresponde a una configuración de su ECHConfigList. No prueba que la lista haya sido autorizada para el public_name, el RRSet de DNS, la cohorte de servidores, el conjunto de reintento y la ventana de rotación correctos.
  • Hace falta un recibo de despliegue de política separado del secreto: una unión verificable entre la configuración decodificada, la publicación DNS, la cobertura del parque, el papel ordinario o de reintento, el periodo de solapamiento y la autoridad que decidió, sin guardar la clave ni divulgar el catálogo de nombres protegidos.

Una prueba válida puede ser demasiado pequeña

El resultado de un validador parece completo. Reconoce los delimitadores PEM, decodifica la clave privada PKCS #8, interpreta la ECHConfigList y comprueba que una de sus configuraciones contiene la clave pública correspondiente. El archivo recibe una marca verde.

Esa comprobación tiene valor real. RFC 9934 nació para que servidores TLS construidos con bibliotecas diferentes pudieran consumir un formato común. El documento dispone que el archivo contenga cero o una clave privada y una lista ECHConfigList. Si incluye la parte privada, al menos una configuración pública debe corresponderle. La lista usa el delimitador ECHCONFIG y solo la parte pública puede publicarse en DNS.

El límite aparece después. La coincidencia interna responde si dos objetos criptográficos guardan la relación esperada. No identifica quién aprobó la incorporación de un dominio a un servidor frontal, qué zona debía publicar la lista, qué máquinas podían custodiar la clave, qué entradas debían ofrecerse como retry_configs ni cuándo concluía la transición.

La precisión matemática invita a extender el significado. Si la relación de claves es indiscutible, el tablero puede presentar el despliegue entero como verificado. Sin embargo, una evidencia fuerte sobre una proposición estrecha no acredita decisiones ajenas. El archivo no es una orden de cambio, un mandato del propietario DNS ni un inventario de cobertura.

Por eso la pregunta completa no es solo si el archivo es válido. Es si ese archivo válido corresponde al estado operativo autorizado.

En una lista caben varias políticas posibles

RFC 9934 admite que una ECHConfigList contenga varias configuraciones en orden decreciente de preferencia. Pueden diferir en extensiones y public_name. Un servidor también puede cargar varios nombres de archivo, y un subconjunto puede reservarse para las configuraciones de reintento.

La flexibilidad permite compatibilidad y transición. Una versión nueva puede convivir con otra que aún atiende a clientes con caché. El servicio puede separar el material empleado normalmente del que ayuda a reparar un rechazo.

Pero cada posibilidad requiere una selección. Dos archivos pueden ser válidos y, aun así, acabar en mitades incompatibles del parque. Una entrada de transición puede quedar primera más tiempo del autorizado. El conjunto de reintento puede omitir la clave que ya se anunció en DNS. Una lista puede incluir dos nombres públicos correctos en sintaxis aunque solo uno pertenezca a la frontera aprobada.

El RFC dice que el contenido posterior a la ECHConfigList debería ignorarse. Es una decisión razonable de formato, pero muestra que una nota pegada al final no es gobernanza. Frases como «solo para el grupo A» o «caduca el viernes» no forman parte de lo que el software debe interpretar.

Tampoco basta la huella de los bytes del PEM. RFC 7468 advierte que su representación textual no es canónica. Dos textos distintos pueden decodificarse en el mismo objeto. Una identidad fiable debe declarar la normalización y calcular una huella sobre la estructura decodificada. Incluso entonces falta vincular el objeto con la autorización externa.

La privacidad depende de quién comparte la configuración

RFC 9849 define public_name como el nombre DNS del servidor orientado al cliente, la entidad en la que se confía para actualizar la configuración. El config_id de un byte ayuda a elegir una clave candidata.

Ninguno funciona como acta institucional. Un nombre válido no demuestra que el propietario de un servicio autorizara ese traslado. El identificador no es global: puede colisionar entre servidores frontales distintos y reutilizarse después de retirar una configuración. Es un selector eficiente, no una identidad histórica de política.

La decisión de agrupar nombres afecta al conjunto de anonimato. Si cada nombre utiliza una configuración diferente, el config_id y otros datos públicos pueden distinguirlos. Compartir la misma configuración entre más nombres puede ampliar el conjunto en el que un observador debe adivinar.

Por eso un archivo perfectamente válido puede materializar un límite demasiado estrecho. La clave coincide. La configuración decodifica. Lo que cambió fue el reparto entre nombres. Separar por error a un dominio crea una señal observable sin romper el PEM.

También existe el error contrario. Unir clientes o servicios bajo una sola clave puede superar una frontera de custodia, contrato o respuesta a incidentes. El máximo conjunto no siempre es la única meta. Más anonimato concentra autoridad y radio de compromiso; más separación puede reducir el anonimato. La decisión correcta debe exponer el criterio y el mandato.

DNS completa la promesa

Los clientes no reciben la clave privada. RFC 9848 usa el parámetro ech de SVCB y HTTPS para publicar la ECHConfigList. Ahí el objeto local se convierte en promesa visible.

El publicador debe garantizar que todas las direcciones a las que conduce TargetName llegan a servidores con la clave privada correspondiente o con autoridad sobre el nombre público. Probar una máquina no demuestra el conjunto. Un nodo olvidado puede producir rechazo o reintento aunque cada archivo examinado por separado sea válido.

RFC 9460 aporta las reglas de selección: el RRSet no tiene orden propio, SvcPriority expresa preferencia, AliasMode cambia el nombre de resolución, ServiceMode aporta alternativas y los parámetros obligatorios determinan compatibilidad. El cliente elige dentro de ese resultado, no dentro del archivo privado.

La superficie de decisión incluye por tanto la lista decodificada, el propietario del RRSet, la ruta de alias, las prioridades, los proveedores y la cohorte de direcciones. Un PEM no sabe si el cambio DNS fue autorizado. Tampoco puede demostrar que una autoridad alternativa anunciada mediante Alt-Svc publicó una configuración coherente.

RFC 9848 desaconseja mezclar registros con ECH y sin ECH. Un intermediario puede bloquear los puntos protegidos y favorecer la alternativa sin ECH. En determinadas condiciones, el cliente debe pasar de un comportamiento SVCB opcional a uno dependiente para no perder privacidad. Aun así, el operador sigue siendo responsable del conjunto que publicó.

La rotación produce una etapa compartida

La sustitución de claves no ocurre a la vez en DNS, servidores y cachés. RFC 9849 recomienda conservar en el conjunto conocido tanto las configuraciones actuales como las anteriores que aún pueden usar clientes con respuestas DNS almacenadas hasta el TTL o incluso más.

El solapamiento es legítimo. La nueva lista puede estar publicada mientras la antigua sigue aceptándose. Una parte del parque puede haber actualizado antes que otra. El conjunto de reintento debe contener claves vigentes. Si un cliente acepta un reintento y el servidor vuelve a rechazarlo, hay una señal probable de configuraciones incompatibles.

La velocidad plantea un compromiso. Rotar pronto limita el daño si una clave se compromete, pero una configuración demasiado efímera reúne menos conexiones y puede reducir el conjunto de anonimato. Retenerla facilita la transición, pero alarga la custodia del secreto.

Nada de eso se codifica como ciclo de vida en el archivo. No contiene la fecha de aprobación, la prueba de publicación DNS, el TTL usado para calcular el solapamiento, el umbral de servidores actualizados, la retirada ni la destrucción. Dos archivos válidos pueden representar un estado previsto y otro olvidado.

Un auditor necesita diferenciar «se mantiene por caché» de «se mantiene porque el despliegue perdió un nodo». Sin una secuencia temporal, ambas explicaciones dejan los mismos bloques PEM.

El alcance exacto de la validación

Un archivo RFC 9934 puede demostrar que la estructura es interpretable y que una clave privada presente corresponde a una configuración. Puede transportar material entre un gestor y software TLS. Puede evitar un error básico de pareja.

Por sí solo no demuestra:

  • que el public_name sea la autoridad aprobada;
  • que el dueño del DNS autorizara esa lista en ese RRSet;
  • que todas las direcciones de TargetName tengan la clave;
  • que la preferencia y el subconjunto de reintento sean los acordados;
  • que los nombres destinados a compartir anonimato usen la misma lista;
  • que servicios que debían permanecer separados no se hayan unido;
  • que la clave anterior solo viva durante el periodo de caché aprobado;
  • que la mezcla de alternativas ECH y no-ECH tenga una excepción vigente;
  • que exista responsable, vencimiento, corrección y vuelta atrás.

No son carencias del algoritmo. Son hechos de autoridad, cobertura y tiempo. Meterlos dentro del mismo archivo secreto tampoco sería prudente: muchos revisores no deben acceder a la clave.

Un recibo de despliegue respetuoso con la privacidad

El recibo debería identificar la ECHConfigList decodificada mediante una huella canónica y registrar el resultado de correspondencia. Nunca copia la clave privada. Para cada entrada, consigna public_name, identificador y papel autorizado: ordinario, reintento, solapamiento o retirado.

Después enlaza esa identidad con una huella canónica del RRSet, su propietario, tipo, modo, TargetName, SvcPriority y parámetros obligatorios. Si hay alias o varios proveedores, deja constancia de la frontera elegida. Una huella de cohorte y una prueba de cobertura bastan para los servidores; no hace falta publicar todas las direcciones.

El tiempo requiere campos propios: aprobación, generación, activación, publicación DNS, inicio del solapamiento, primera retirada segura, retirada efectiva y destrucción. El cálculo debe citar TTL y margen de caché. La comprobación incluye los conjuntos ordinario y de reintento, además de un agregado de dobles rechazos.

La política del conjunto de anonimato puede expresarse como clase de separación, rango de tamaño y umbral que obliga a reaprobar. No debe enumerar dominios de clientes. Los ensayos pueden usar nombres controlados y resultados agregados.

El recibo también nombra al aprobador, la autoridad ejercida, versión de política, excepción, vencimiento, destino de vuelta atrás, versión del evaluador y estado de corrección. Si una decisión cambia, el registro debe decirlo en vez de borrar la primera explicación.

Así se conserva una frontera sana. El auditor ve la decisión y las pruebas de cobertura; la clave y el mapa de nombres siguen restringidos. La rendición de cuentas no debería reconstruir el historial de navegación o alojamiento que ECH protege.

Lo que las fuentes no establecen

Los RFC no documentan un fallo real de un proveedor. No acreditan una clave filtrada, un conjunto dividido, una tasa de rechazo, una adopción determinada ni una infracción jurídica. El término «límite equivocado» describe la diferencia entre el estado autorizado y el desplegado; no acusa a una implementación citada.

El recibo es una propuesta editorial, no una exigencia de RFC 9934. Un sistema maduro puede guardar evidencia equivalente en control de claves, DNS e inventario. Lo decisivo es que pueda unirla y que no llame a la validez interna prueba de todo el despliegue.

La conclusión es sencilla: validar y proteger el archivo, y después revisar la decisión que lo rodea. La frontera de privacidad aparece cuando la lista correcta se publica en el DNS correcto, llega a los servidores correctos, agrupa los nombres correctos y se retira en el momento correcto.

Sources

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9934/
  5. https://www.rfc-editor.org/rfc/rfc9934.html
  6. https://www.rfc-editor.org/rfc/rfc9849.html
  7. https://www.rfc-editor.org/rfc/rfc9848.html
  8. https://www.rfc-editor.org/rfc/rfc9460.html
  9. https://www.rfc-editor.org/rfc/rfc7468.html
  10. https://www.rfc-editor.org/rfc/rfc9525.html
  11. https://www.rfc-editor.org/rfc/rfc8446.html
  12. https://www.rfc-editor.org/rfc/rfc9180.html
  13. https://www.rfc-editor.org/rfc/rfc9364.html
  14. https://www.iana.org/assignments/dns-svcb/