Resumen

  • Una cadena TLSA validada puede iniciar un ExtSupportLifetime para el nombre SNI y puerto concretos. El TTL limita la vigencia del registro actual; el pin obliga a que el canal de evidencia siga respondiendo durante otro plazo.
  • Una negación autenticada, una prueba de delegación insegura o una transición DANE validada con duración cero pueden borrar el pin. La falta de extensión cuando el cliente aún la exige no demuestra ausencia y obliga a detener o abortar.

Cuando el DNS necesario todavía no está disponible

Un cliente de DNS sobre TLS quiere saber si está hablando con el resolvedor correcto. DANE puede vincular el certificado al dominio mediante un TLSA protegido por DNSSEC. Pero pedir ese registro a través del mismo servicio que aún se intenta autenticar introduce una dependencia circular. La extensión dnssec_chain de RFC 9102 permite que el servidor entregue dentro del handshake TLS todos los registros necesarios para reconstruir la cadena DNSSEC.

El paquete trae una cadena y un contador de horas. La cadena prueba el estado actual; ExtSupportLifetime expresa cuánto tiempo el servidor, o el clúster que sirve ese nombre, se compromete a seguir ofreciendo la extensión. Las dos cosas viajan juntas, pero no comparten vencimiento.

Shumon Huque figura como coautor junto con Viktor Dukhovni, Willem Toorop, Paul Wouters y Melinda Shore. El RFC reconoce a Adam Langley como autor de la idea original. El perfil IETF y la biografía de Huque describen una trayectoria en infraestructura DNS, redes y protocolos de seguridad, actualmente en Salesforce y antes en Verisign y la Universidad de Pensilvania. Esa atribución sitúa su contribución; no convierte el texto experimental ni las tecnologías que enlaza en propiedad de una persona.

La observación no basta para fijar nada

El pin solo nace de una señal fuerte. El cliente puede usar un valor no nulo únicamente si la respuesta incluye una cadena TLSA válida que concuerda con el certificado del servidor y el handshake termina autenticado por DANE. Ver el campo, validar solo la sintaxis o aceptar el certificado por PKIX no genera el mismo compromiso.

Su clave de estado también es estrecha. La petición lleva el puerto TCP y usa el nombre SNI del cliente. El servidor no expande un CNAME para sustituir esa base TLSA en el método incorporado. De este modo, el pin pertenece a un par nombre-puerto y no se derrama sobre todas las direcciones, servicios o empresas alojadas en la misma máquina.

El servidor propone una duración; el cliente puede recortarla a su máximo local. El documento menciona el caso teórico de un servidor comprometido que anuncie siete años. Un tope prudente limita ese poder, aunque reducirlo demasiado debilita la protección contra degradación. La política local forma parte del resultado efectivo.

Un registro corto dentro de una promesa larga

Un TLSA validado puede permanecer en caché hasta su TTL. Mientras siga vigente, el cliente puede reutilizarlo y no pedir la extensión en cada conexión. Después del TTL, ese mismo RRset ya no sirve como prueba, aunque el pin tenga días o meses por delante. El cliente debe obtener material nuevo.

Conviene pensar en dos relojes. El primero mide frescura: TTL y validez de RRSIG. El segundo mide obligación de servicio: hasta cuándo debe existir una forma verificable de obtener el estado actual. RFC 9102 declara que la duración del pin no está limitada por los TTL ni por el vencimiento de las firmas, precisamente porque no alarga esos datos; exige que puedan renovarse.

La reanudación TLS requiere otra distinción. En una sesión reanudada no se envía dnssec_chain; en TLS 1.3 tampoco vuelve el mensaje Certificate al que se adjuntaría. Contar esa ausencia como fallo sin mirar la caché y el tipo de handshake produce falsos incidentes. El recibo operativo necesita los cuatro datos.

La prueba negativa conserva autoridad

Si el dominio elimina TLSA, el servidor puede entregar NSEC o NSEC3 y la cadena que autentica esa inexistencia. Una negación válida borra el pin. También puede hacerlo una prueba de delegación insegura. A partir de ahí, la política del cliente decide si una autenticación PKIX es suficiente o si la conexión debe cerrarse.

No ocurre lo mismo cuando la extensión simplemente falta. Con un pin vivo y sin un TLSA vigente en caché, el cliente debe exigir una extensión que contenga un TLSA válido o una prueba de inexistencia que cubra el nombre y el puerto. Si el servidor calla, el cliente detiene el tráfico mientras intenta obtener evidencia fuera de banda; si tampoco la consigue, aborta. El silencio no hereda la autoridad de una prueba negativa.

Esta separación impide un ataque de degradación sencillo. Un intermediario que disponga de un certificado aceptable por PKIX no puede borrar DANE omitiendo la extensión y beneficiarse de una caída automática a WebPKI. Para levantar el estado anterior hace falta una transición autenticada.

Por ello el propio RFC advierte que exigir la extensión no significa exigir TLSA, DANE ni DNSSEC indefinidamente. El operador de la zona puede retirar el TLSA o el DS. Durante el plazo comprometido, el servicio solo debe seguir entregando el estado verificable: positivo mientras exista, negativo cuando haya dejado de existir.

Desactivar es una operación de dos tiempos

Para abandonar la extensión, el operador primero anuncia cero dentro de un handshake autenticado por DANE. Después mantiene el soporte hasta que hayan vencido todos los pines no nulos emitidos anteriormente. Solo entonces lo apaga. Si elimina antes TLSA o DNSSEC, todavía debe poder servir la negación correspondiente a quienes conservan pines.

La regla revela una frontera empresarial. El dueño del dominio puede querer migrar; el proveedor de alojamiento puede controlar certificados, balanceadores y generadores de cadena. RFC 9102 recomienda una duración no nula solo mediante acuerdo mutuo. Una promesa del clúster falla si uno de sus nodos desconoce el compromiso.

El cliente, además, no acepta como ancla lo que el servidor acaba de enviar. Valida desde un trust anchor DNSSEC preconfigurado, mantiene sus cambios de clave y necesita una hora aproximadamente correcta para juzgar RRSIG. Llevar la cadena por TLS resuelve el transporte, no el origen último de confianza.

El carácter experimental no es un pie de página. El grupo TLS expresó dudas sobre el coste de desplegar el pin y el documento propone aprender de implementaciones reales. Las fuentes revisadas no cuantifican la adopción actual. Lo que sí dejan es una frontera reusable: afirmación positiva, negación autenticada y dato ausente producen decisiones diferentes.

Fuentes