Resumen

  • ECH convierte el registro HTTPS/SVCB en configuración criptográfica activa: la clave pública solo sirve cuando el edge alcanzado por el cliente dispone de la clave privada correspondiente.
  • La unidad de control es la ventana entre la primera publicación DNS y la preparación total de la flota, medida con aceptación, rechazo, retry, desactivación segura y fallo.
  • Las configuraciones de retry corrigen desfases limitados; no convierten la publicación en una operación atómica ni justifican ciclos persistentes.
  • Las plataformas integradas pueden internalizar custodia, solapamiento y telemetría. La competencia multi-proveedor necesita recibos portables de versión y activación.

El DNS distribuye algo más que una dirección

RFC 9849 define un ClientHelloInner privado y un ClientHelloOuter visible. El inner contiene el nombre real y preferencias sensibles; el outer transporta la envoltura cifrada. El servidor frontal necesita la clave privada correspondiente a la ECHConfig que obtuvo el cliente.

RFC 9848 especifica la publicación del parámetro ech mediante service bindings. RFC 9460 reúne endpoint y parámetros en registros SVCB/HTTPS. El registro ya no es una nota sobre el servicio: participa en la construcción del primer mensaje TLS.

Por eso importa el orden. Activar primero exige mantener dos versiones. Publicar primero crea una ventana en la que el cliente puede alcanzar un edge sin la clave. El certificado sigue válido y el HTTPS corriente puede funcionar. Ninguna de esas señales demuestra aceptación ECH en el primer intento.

Cuatro estados para una conexión

El navegador decide si ofrece ECH. La política de Chrome Enterprise aclara que el uso también depende del soporte del servidor, del registro HTTPS y del despliegue. La FAQ de Firefox documenta la activación por defecto desde Firefox 119 y las rutas de desactivación empresarial, parental o mediante middlebox de confianza.

El resolver decide qué recibe el navegador. RFC 9460 reconoce que suprimir SVCB puede negar el beneficio. La documentación de Cloudflare describe la supresión de respuestas HTTPS y el dominio canario como controles locales, y advierte sobre reescrituras incompatibles con DNSSEC.

El DNS autoritativo controla versión, TTL y alias. La flota edge controla la clave privada en cada cohorte. La evidencia mínima debe enlazar hash de ECHConfigList, primera observación DNS, TTL, activación por cohorte, aceptación, retry y cola de cachés obsoletas.

Un segundo intento no borra el primero

ECH permite que el servidor entregue configuraciones de retry. La reparación es parte del diseño, pero su semántica es concreta: el cliente encontró una configuración que no servía para el servidor alcanzado y pagó otra conexión para corregirla.

RFC 9849 desaconseja aceptar otra configuración de retry cuando la conexión ya procede de un retry. También señala configuraciones múltiples e incoherentes como posible error. Si cada respuesta anuncia una versión más autorizada que la anterior, la flota no tiene una versión autorizada.

El operador debe contar retry por versión, resolver, cliente y edge. Una cola breve durante una rotación puede estar controlada. Una concentración sostenida en una ubicación es un incidente. El promedio global es capaz de ocultar un rack entero con notable profesionalidad.

La privacidad necesita coherencia externa

El objetivo de ECH no termina al cifrar SNI. El conjunto de anonimato requiere que los servicios compartan una apariencia externa compatible. Cookies de HelloRetryRequest, nombres de clave, orden de extensiones y errores distintos podrían identificar un backend. Las normas describen ese mecanismo de riesgo; este paquete no mide una degradación del conjunto de anonimato en un despliegue concreto.

RFC 9849 trata estos riesgos, especialmente en modo dividido. RFC 9934 normaliza un archivo PEM que puede incluir clave privada y ECHConfigList coincidente. Eso resuelve el formato, no la distribución. Un archivo correcto en el controlador no prueba que un edge lo haya cargado.

RFC 9180 define HPKE, la construcción criptográfica subyacente. Puede proteger perfectamente el contenido y, al mismo tiempo, cifrarlo para la clave que el último edge aún no conoce.

La ventaja de la plataforma integrada

Un proveedor de DNS y edge puede preparar la clave, verificar la flota, publicar, mantener solapamiento, observar retries y retirar la versión anterior dentro de un sistema. Cloudflare indica que ECH está activado por defecto en zonas Free y es configurable en otros planes. No es una estadística universal de éxito; sí muestra que la coordinación puede venderse como propiedad del producto.

El dominio multi-CDN debe acordar configuración compartida, varios service bindings o diferencias por ruta. Custodia de secretos, TTL, cachés, rollback y disponibilidad se convierten en términos contractuales. La norma abre la puerta; no coordina los calendarios.

El lock-in aparece cuando solo un proveedor puede demostrar qué versión estaba activa y dónde. La salida exige recibos portables: hashes, tiempos, cohortes, aceptación y reversión. Sin ellos, migrar ECH consiste en volver a aprender bajo tráfico real.

La conclusión sobre coordinación y lock-in es una inferencia analítica de controles divididos, no una condición de mercado observada. El dueño del dominio paga planificación de solapamiento y portabilidad; el proveedor DNS, publicación, TTL y evidencia de caché; el operador edge, distribución del secreto, telemetría y rollback; la empresa, pruebas de política del resolver y soporte; y el usuario, primeros intentos fallidos y latencia de retry. Un contrato puede reasignar dinero y trabajo, pero no eliminarlos.

Criterios antes de celebrar

Cada rotación debería producir un ledger con hash, observaciones DNS, TTL, flota prevista, activación, aceptación inicial, retry, latencia, desactivación, fallos y rollback.

La tesis pierde fuerza si rotaciones independientes muestran publicación solo después de que al menos 99,999 % de edges estén listos, desfases por debajo de 0,01 %, coste p99 de retry inferior a 25 ms, desaparición dentro de TTL más 30 segundos y traspasos multi-proveedor equivalentes sin orquestación común. Gana fuerza si más del 1 % de primeros intentos requiere retry, una cohorte supera dos TTL o el rollback tarda más de 300 segundos.

Son umbrales de rechazo futuros, no cifras observadas. La diferencia evita convertir una hipótesis medible en una cuota de mercado imaginaria.