Resumen

  • El propietario DNS de TLSA combina puerto, protocolo de transporte y dominio base. La coincidencia acredita una asociación para ese servicio y ese modelo de validación, no una confianza universal en el certificado o el host.
  • Para poder repetir la decisión hay que guardar el nombre consultado, el estado DNSSEC, el uso, el selector, el tipo de coincidencia, el material del handshake, la regla de la aplicación y el instante de observación.

Una huella no es un ámbito

Imaginemos un ensayo controlado. Un servidor presenta el mismo certificado en TCP 443 y 8443, pero su zona firmada sólo publica TLSA bajo _443._tcp.service.example. El cliente de 443 valida la cadena DNSSEC y compara el objeto señalado. El cliente de 8443 debe buscar _8443._tcp.service.example. Que vea el mismo certificado no le permite importar la decisión del otro puerto.

El caso es ilustrativo y no atribuye un fallo a ningún producto. Sirve para probar una abstracción habitual: almacenar la huella como si acumulase reputación DANE. RFC 6698 puso el puerto y el transporte en el nombre precisamente para impedir esa expansión silenciosa. Dos servicios en el mismo host pueden tener asociaciones, responsables y calendarios de cambio diferentes.

Si la base de datos conserva «certificado aprobado» y elimina el nombre TLSA, ya no tiene una prueba; tiene una conclusión separada de su jurisdicción.

El nombre se deriva, no se improvisa

En TLS directo sobre TCP, la forma típica es _puerto._tcp.dominio-base. El puerto se escribe como número decimal. El protocolo de transporte forma parte de la selección. El dominio base procede de las reglas de la aplicación.

Una cadena de CNAME puede cambiar el punto final de la consulta. Los protocolos que descubren servicios mediante SRV siguen RFC 7673. SMTP DANE parte de MX y aplica reglas específicas a los nombres base, los identificadores de referencia, los errores DNS y el repliegue. Por eso ni la IP conectada ni el nombre que aparece al final de una traza bastan para explicar la autoridad.

La evidencia debe conservar el destino original, la secuencia MX/SRV/CNAME, los nombres antes y después de expansión, el puerto, el transporte, la consulta TLSA exacta, el resultado DNSSEC y la norma de aplicación usada. Sólo así otro equipo puede repetir la decisión.

Cuatro usos, cuatro decisiones de confianza

PKIX-TA(0) limita una CA pero mantiene la validación PKIX. PKIX-EE(1) limita el certificado final y también exige una ruta PKIX válida. DANE-TA(2) publica una asociación de ancla mediante DNSSEC. DANE-EE(3) asocia directamente el servicio con un certificado final o su clave.

Una coincidencia binaria no borra estas diferencias. Con uso 1, el objeto seleccionado puede coincidir y aun así fracasar por caducidad o por una ruta inválida. Con uso 3, no corresponde inventar controles de nombre ajenos al perfil de la aplicación. SMTP DANE restringe además qué usos tienen sentido en su modelo oportunista.

La pregunta operativa completa incluye quién publicó el uso, bajo qué zona firmada, qué cliente lo implementó y qué política de aplicación decidió el fallo.

Selector y matching type cambian el objeto

El selector 0 toma el certificado DER completo. El selector 1 toma SubjectPublicKeyInfo. Un certificado renovado puede mantener la clave: en ese caso cambia el primer objeto, pero el segundo puede continuar idéntico.

El tipo de coincidencia 0 usa los bytes seleccionados; 1 usa SHA-256; 2 usa SHA-512. Una cadena hexadecimal sin esos dos campos no dice qué se comparó.

La elección define costes y riesgo. Anclar el certificado completo obliga a coordinar cada renovación. Asociar SPKI facilita renovaciones con la misma clave, pero una clave comprometida conserva más alcance. Una ancla DANE tiene otro radio. El diseño correcto depende de custodia, automatización y recuperación, no de una jerarquía universal de números.

Sin DNSSEC seguro no hay autoridad DANE

Recibir un RR tipo 52 bien formado no basta. El validador debe diferenciar secure, insecure, bogus e indeterminate. Un Extended DNS Error aporta diagnóstico, no sustituye la comprobación criptográfica.

Una respuesta no firmada no puede reducir las exigencias de certificado. En sentido inverso, cuando un perfil considera vinculante un RRset seguro y utilizable, retroceder en silencio después de un fallo reabre una vía de downgrade. En SMTP DANE, si existe una asociación segura utilizable y la autenticación falla, no se debe entregar por ese servidor.

DNSSEC autentica la publicación bajo un nombre. No prueba custodia exclusiva de la clave TLS ni corrección del servicio. Si cae la firma DNS, un atacante puede publicar otro DANE-EE; si cae la clave TLS, puede satisfacer el registro existente. Son dos planos de control diferentes.

La autorización de aplicación viene después

TLSA puede acreditar que el material del handshake coincide con una asociación. No decide ALPN, autoridad HTTP, identidad del cliente, permiso de usuario ni resultado de la transacción.

Un proxy termina una conexión y crea otra frontera. La prueba del tramo exterior no se transfiere al backend. Compartir un certificado final entre servidores no equivalentes también permite sustitución dentro del conjunto. RFC 7672 aconseja evitarlo salvo que los destinos sean funcionalmente equivalentes o que sus protocolos impidan obtener ventaja.

El lenguaje auditable es limitado: «el SPKI presentado coincidió con el uso 3 seguro para este nombre y este momento». «El dominio autorizó la solicitud» excede la prueba.

Cambiar claves exige tiempo observable

Una transición robusta publica primero el material nuevo, mantiene una superposición, observa cachés y clientes, y retira el material anterior cuando TTL, firmas y endpoints lo permiten. Renovar con la misma clave puede no cambiar SPKI; rotar la clave sí. Cambiar una ancla no es igual que cambiar el certificado final.

Hay que fechar publicación autoritativa, visibilidad recursiva, despliegue del certificado, retirada y validez de RRSIG. Un único resolver verde no demuestra convergencia.

La prueba negativa debe cruzar la frontera

Use el mismo certificado en dos puertos y publique TLSA para uno. Cambie el transporte. Añada CNAME, SRV y MX. Haga coincidir los bytes de PKIX-EE mientras rompe la ruta PKIX. Renueve con la misma clave y luego con una nueva durante superposición.

Produzca estados secure, insecure, bogus e indeterminate. Deje pasar TLSA y falle ALPN o el permiso de aplicación. El resultado correcto es una colección de pruebas separadas, no un único indicador verde.