Resumen

  • RFC 9934 define un archivo PEM con cero o una clave privada PKCS #8 y una sola ECHConfigList; si hay secreto, una configuración pública de la lista debe corresponderle.
  • Esa relación protege la coherencia del paquete local, no la sincronía con el proceso TLS, el RR HTTPS/SVCB, las cachés, la decisión ECH del cliente ni la privacidad observable.

El error más peligroso de una cadena ECH no siempre es una clave incorrecta. Puede ser una clave perfectamente correcta en el lugar equivocado. Un validador abre el archivo, reconoce PRIVATE KEY, decodifica ECHCONFIG y confirma la correspondencia. Mientras tanto, la zona publica la generación siguiente y algunos resolutores entregan todavía la anterior. Tres estados válidos producen una sola negociación fallida.

La RFC 9934 ofrece un lenguaje común para trasladar material ECH entre gestores de claves, bibliotecas TLS y servidores. El archivo contiene cero o una clave privada y una ECHConfigList. Si existe la clave, va primero, se codifica como PrivateKey PKCS #8 y usa el rótulo PRIVATE KEY. Después aparece la lista pública en base64 bajo el rótulo ECHCONFIG. Uno de sus miembros debe contener la clave pública correspondiente.

Es un contrato exacto, pero no total. El archivo puede no llevar clave privada. La lista puede incluir varias configuraciones, por ejemplo con extensiones o public_name distintos, y se ordena de mayor a menor preferencia. El servidor puede leer varios archivos y escoger sólo algunas listas para las configuraciones de reintento. Validar una pareja no demuestra que el proceso posea todos los secretos anunciados.

La norma fija además una frontera de publicación inequívoca: la ECHConfigList puede copiarse al DNS mediante un registro HTTPS; la clave privada no debe publicarse allí. La automatización necesita dos salidas con reglas distintas. Si genera un único artefacto para ambas, puede filtrar el secreto. Si las separa sin una identidad de generación verificable, puede publicar una lista que ya no coincide con el servidor.

La RFC 7468 normaliza límites textuales y reconoce que los analizadores históricos difieren en espacios y etiquetas. La RFC 4648 hace portable la representación base64. Ninguna convierte un bloque legible en constancia de instalación o custodia. El control práctico incluye cuentas de despliegue, copias de respaldo, instantáneas y accesos de soporte, no sólo el propietario nominal del archivo.

En RFC 9849, el servidor necesita conservar tanto las configuraciones publicadas como las anteriores que un cliente podría mantener durante el TTL o más. Un cliente ofrece una configuración y el servidor intenta descifrar el ClientHello interno. Si lo logra, puede aceptar ECH. Si no, usa el ClientHello externo, rechaza ECH y puede devolver retry_configs. La conexión rechazada no se convierte por eso en una sesión de aplicación válida.

Esto convierte la rotación en una transición distribuida. Deben concordar la creación, el archivo instalado, la memoria activa, la zona autoritativa, las cachés recursivas y el estado de reintento. La secuencia debe tolerar clientes atrasados sin conservar secretos indefinidamente. El rollback también tiene dos lados: restaurar sólo el DNS o sólo el servidor puede aumentar la incoherencia.

Una prueba defendible empieza por el identificador no secreto de generación y el hash del archivo. Añade resultado de parseo, cardinalidad, coincidencia de claves, permisos y recibo de despliegue. Continúa con el hash del conjunto activo del servidor, el RRSet autoritativo, observaciones recursivas con edad, lista recibida por el cliente, config_id, aceptación o rechazo, hash de reintento, validación de certificado y Finished. Termina con una observación independiente de la aplicación. El secreto no se copia al expediente.

La RFC 9848 impide confundir aceptación con anonimato universal. Mezclar destinos con y sin ECH permite degradación selectiva. El DNS en claro, la dirección IP, el análisis de tráfico o un conjunto pequeño pueden revelar información. RFC 9460 vuelve interoperable el anuncio del servicio; no inspecciona la clave privada ni la memoria del servidor.

La doctrina de Heng Lu ayuda a asignar autoridad. El analizador de archivos describe una representación. El proceso en ejecución describe su estado. El DNS describe una publicación. El cliente describe una negociación. La aplicación describe un resultado. Convertir el primer registro verde en portavoz de todos los demás es precisamente la confusión que un sistema de evidencia debe evitar.

La especificación mínima común permite usar bibliotecas distintas sin imponer un gestor de claves central. Las decisiones futuras —cadencia, TTL, solapamiento, borrado, reintento y medición— permanecen locales. La libertad de adoptarlas no incluye la libertad de ocultarlas bajo un único indicador.

Fuentes