Resumen

  • Un RRset TLSA solo se convierte en evidencia DANE mediante su resultado DNSSEC: los datos inseguros o indeterminados son inutilizables y los datos bogus obligan a fallar.
  • El uso del certificado, el selector y el tipo de coincidencia determinan qué se compara y qué validación se aplica.
  • Una asociación publicada de forma segura todavía puede ser inutilizable o no coincidir con el certificado o la clave que presenta el servidor.
  • El control debe separar los estados publicado, seguro, utilizable, coincidente y aceptado.

Imaginemos que el certificado de un servicio se renueva correctamente a medianoche. La nueva cadena ya está en todos los servidores, pero algunos clientes conservan en caché una asociación TLSA de la clave anterior. DNS contiene TLSA, el extremo HTTPS parece sano y el ticket se cierra. Esos clientes abortan porque la asociación autenticada ya no coincide con la clave servida.

La traza es hipotética. Muestra la distancia entre publicar una asociación y reconciliar todos los elementos necesarios para aceptarla.

Publicar es solo el primer estado

RFC 6698 compone TLSA con uso de certificado, selector, tipo de coincidencia y datos de asociación. Los tres parámetros determinan si la asociación restringe una ruta de CA pública, aporta un ancla de confianza o identifica un certificado final emitido por el dominio; si se compara el certificado completo o SubjectPublicKeyInfo; y si se usan bytes exactos, SHA-256 o SHA-512.

El nombre de consulta también deriva del puerto, el transporte y el dominio base TLSA. Consultar otro servicio o detenerse en un alias inseguro puede ofrecer bytes DNS válidos para una decisión equivocada. RFC 7671 incorpora la expansión CNAME segura al dominio base preferido. Guardar solo el RDATA borra la identidad del servicio al que debía aplicarse.

DNSSEC decide si la asociación puede usarse

RFC 6698 hace decisivo el estado DNSSEC. Un RRset TLSA seguro debe utilizarse salvo que la política local prohíba esa asociación concreta. Una respuesta bogus debe impedir o abortar TLS. Un RRset inseguro o indeterminado no sirve para autenticar TLS.

«Publicado en DNS» es más débil que «validado como seguro», y seguro aún no significa utilizable. Un uso, selector o tipo desconocido vuelve inutilizable la asociación. Lo mismo ocurre con datos mal formados o algoritmos demasiado débiles para la política del cliente.

Cuando no queda ninguna asociación utilizable, la aplicación procesa TLS de la forma habitual, sin entrada TLSA. Cuando hay una o más, ejecuta las comparaciones requeridas y debe obtener una coincidencia. Dos clientes con capacidades o políticas distintas pueden tratar de manera diferente el mismo RRset sin negar que fue publicado.

El certificado servido todavía debe satisfacer el registro

El uso cambia lo que significa coincidir. Algunos usos conservan la validación PKIX; los usos DANE pueden establecer un ancla respaldada por DNSSEC o asociar directamente la entidad final. El selector define si una renovación con la misma clave continúa coincidiendo o si importa cada byte del certificado.

RFC 7671 añade obligaciones operativas. DANE-TA necesita que el servidor entregue material suficiente de la cadena y, en ciertos casos, el certificado del ancla. DANE-EE con selector SPKI puede sobrevivir a la renovación si la clave no cambia, pero falla si el servidor presenta otra. La agilidad de resumen se aplica después de descartar asociaciones mal formadas o no soportadas.

La salud del servidor no equivale a salud DANE. Un cliente PKIX convencional puede completar TLS mientras un cliente DANE debe rechazar. Una aplicación oportunista puede continuar con TLS no autenticado cuando no hay asociaciones seguras utilizables, pero una política de autenticación obligatoria no puede conectarse. La aceptación es una decisión del protocolo y del cliente.

El tiempo también separa publicación y aceptación

El TTL de TLSA, la vigencia de RRSIG, la edad del caché y el orden de despliegue limitan la observación. RFC 7671 advierte que una asociación TLSA obsoleta en caché puede provocar fallos tras un cambio imprevisto del certificado o la cadena. Una firma demasiado larga también prolonga el periodo en que se pueden reproducir datos DNS firmados.

La rotación debe coordinar asociaciones antiguas y nuevas, publicación autoritativa, secundarios, cachés de validadores, despliegue del servicio y reversión. Ver el nuevo registro en un servidor autoritativo no prueba qué vínculo ven los clientes reales.