Resumen

  • La revisión 12 es un Internet-Draft Experimental activo, no un RFC ni evidencia de implementación o despliegue.
  • El documento HTTPS expresa el estado que desea un origen; la inscripción del operador define qué nombre, tipo y puerto puede modificar la zone factory.
  • Autenticar un origen no concede autoridad sobre otros servicios, y validar JSON no prueba publicación DNS, convergencia, ECH o resultado.
  • Los clientes generales no deben usar el well-known como sustituto del DNS porque el arranque expone el nombre y permite configuración individualizada.

La autenticación necesita un objeto de autoridad

Los registros SVCB y HTTPS distribuyen parámetros de conexión mediante DNS. Para coordinar configuraciones ECH que giran en sistemas separados, el borrador propone que un origen publique JSON en /.well-known/origin-svcb y que una zone factory lo convierta bajo política local.

HTTPS responde quién sirvió el documento para un origen concreto. No responde qué owner name, tipo de registro o puerto puede escribir ese documento. Para un servicio en 8443, la zone factory debe acceder al origen que incluye ese puerto al considerar el nombre HTTPS con prefijo de puerto.

Un archivo en 443 no descubre automáticamente otro servicio del host. La coincidencia de dirección IP tampoco transfiere autoridad. La inscripción debe unir explícitamente origen, puerto, owner, tipo, política y responsable.

El valor por defecto protege el DNS

La zone factory no debería sintetizar registros desde documentos encontrados en su configuración inicial. Activar la función debería exigir un cambio del operador. Así, publicar un archivo accesible no se convierte por accidente en una delegación.

Para nombres compatibles con SVCB que no corresponden naturalmente a un origen HTTP, el operador necesita indicar el owner completo, el tipo y la URL o ruta local de la fuente. No existe en general un origen intrínsecamente autorizado a controlar cualquier registro.

La inscripción es un recibo persistente. Debe tener epoch, aprobador, límites y procedimiento de retirada. La mera presencia del recurso no lo sustituye.

JSON deseado, zona aplicada, cliente observado

Una respuesta 200 demuestra que se obtuvo un cuerpo. No demuestra que se pudo convertir, que la política lo aceptó, que la zona cambió o que un cliente vio el RRset.

Conviene separar estado deseado, decisión de validación, fragmento generado, estado autoritativo y estado distribuido. Cada uno tiene hash y tiempo. El serial de una autoridad tampoco prueba que todas las secundarias y cachés convergieron.

El panel que reduce todo a «sincronizado» pierde dónde se detuvo el cambio. La cadena completa conserva documento, normalización, RRset, commit, sondas autoritativas, TTL, observación del resolver y selección del cliente.

Parsear no equivale a aprobar

El objeto contiene regeninterval y endpoints; claves superiores desconocidas se ignoran y una lista vacía es error. ServiceMode y AliasMode pueden expresar objetivos y parámetros, pero el resultado debe respetar SVCB/HTTPS.

Si un SvcParamKey no se puede convertir o el fragmento falla validación, no se debe actualizar DNS. Esa negativa quizá no sea visible para el origen. Registrar sólo el fetch verde transforma una protección en falso éxito.

La evidencia incluye identidad del certificado, body hash, veredicto de parser, endpoints normalizados, campos rechazados, RRset generado, versión de política y decisión final. «Sin cambio», «cambio inválido» y «válido pero denegado» no son iguales.

Un test no cubre todos los endpoints

La zone factory debería comprobar que ECH funciona antes de publicar. Puede necesitar un cliente especial que use una ECHConfigList aún no publicada y observe el resultado real de ECH.

La lista puede contener valores que fallan intencionadamente por GREASE. En multi-CDN, un test puede llegar sólo a una dirección. Si hints difieren de A/AAAA, hay que autenticar el backend por webPKI en todas las direcciones relevantes.

El recibo de cobertura enumera endpoint, familia, configuración, expectativa GREASE, certificado, ALPN, puerto y resultado. Una conexión correcta no firma el resto de la lista.

Las rotaciones tienen varios relojes

regeninterval indica cuándo podría generarse un reemplazo, no una caducidad exacta. La zone factory debería fijar TTL menor e intentar refrescar antes, pero generación, polling, commit, replicación y cachés avanzan por separado.

El borrador admite cierta extensión de vida gracias a retry_configs; borrar precipitadamente registros o direcciones puede causar otro tipo de fallo. Por eso el instante del JSON no puede declarar convergencia global.

Varias zone factories pueden producir RRsets diferentes bajo políticas distintas. La reconciliación necesita hashes semánticos, seriales y sondas, no sólo comparar texto JSON.

Split mode añade otra transferencia

En ECH split mode, el client-facing server descifra el ClientHello exterior y el backend procesa el interior. El backend puede obtener parámetros del CFS, después presentar su propio JSON a la zone factory.

Autenticar el documento del backend no prueba cómo obtuvo los valores del CFS. Esa transferencia necesita canal autenticado y recibo separado. El origen sigue siendo responsable de reflejar correctamente intermediarios y aliases.

Una cadena operativa debe identificar quién generó el material, quién lo adoptó, quién lo publicó y qué extremo lo usó. Un solo campo «proveedor ECH» borra autoridades distintas.

Retirarse no es devolver 404

La revisión no especifica cómo añadir o quitar orígenes de la lista de polling ni cómo pedir eliminar todos los HTTPS RR. JSON antiguo puede seguir accesible después de abandonar el mecanismo y provocar publicación no deseada.

Tampoco es seguro interpretar un 404 como orden de borrado: puede ser temporal. La retirada requiere autoridad, fecha efectiva, reemplazo o eliminación, serial y observación de drenaje de caché.

ECH, hints y aliases pueden necesitar fallos distintos. La organización debe decidirlos antes de una interrupción.

La interfaz de control no es descubrimiento del cliente

Aunque el recurso sea público, un cliente HTTP general no debería usarlo en lugar de consultar HTTPS/SVCB por su resolver. La conexión inicial no puede usar ECH y revela el nombre protegido.

El origen también podría responder con una configuración única para cada visitante y crear rastreo. DNS agrega y almacena de modo distinto; transportar parámetros parecidos no vuelve equivalentes ambos canales.

La telemetría del cliente conserva resolver, generación, edad de caché, endpoint, ECHConfig, handshake y resultado. El fetch JSON pertenece al plano de control.

Una intrusión breve puede dejar estado duradero

Valores erróneos pueden producir fuga de privacidad o uso excesivo de retry_configs. Como webPKI puede depender de DNS o HTTP para demostrar control, una intrusión temporal en el backend podría influir en hints y, con validación débil, ayudar a obtener control más largo.

Es un análisis de riesgo, no un incidente observado. Los hints divergentes se comparan con A/AAAA y se autentican en todas las direcciones. CAA ofrece contexto adicional. Enrutamiento e identidad no deben cerrarse con la misma entrada comprometible.

El servidor de archivos también debe impedir traversal o enumeración que alcance claves privadas ECH junto al material público.

Fuentes y límites

El paquete congelado incluye la revisión 12, registros oficiales, TLS WG, SVCB/HTTPS, bootstrap ECH, ECH, URI well-known, TLS 1.3, ACME, CAA, registros IANA y key-share prediction.

Las fuentes establecen texto de protocolo y riesgo. No prueban zone factory, actualización DNS, ECH, convergencia, certificado, rastreo, ataque ni resultado real. La apertura es un caso construido.

Fuentes