Resumen

  • La revisión 14 de draft-ietf-dance-client-auth se publicó el 11 de septiembre y sigue en Working Group Last Call. Todavía es trabajo en curso, no un RFC ni un estándar aprobado.
  • El servidor trata cuatro entradas como resultados distintos de un conjunto TLSA validado por DNSSEC: fallo de validación, respuesta no autenticada, NXDOMAIN y NODATA. Ante cualquiera, debe cerrar o, si su política lo permite, continuar con el cliente como no autenticado.
  • Un recibo operativo mínimo puede preservar clase de respuesta, modo de confianza, versión de política y autorización posterior, sin alterar el protocolo ni publicar identidades sensibles.

La noticia no es una aprobación

El Datatracker fecha el 11 de septiembre de 2026 la revisión 14 de “TLS Client Authentication via DANE TLSA records”. Es un documento del grupo DANCE, activo en el Área de Seguridad. Busca una futura categoría Proposed Standard, pero la página aún muestra Working Group Last Call y seguimiento del document shepherd. En IESG figura Waiting for AD Go-Ahead::AD Followup.

Esos rótulos delimitan dónde está el expediente; no certifican su llegada. El historial registra que la revisión 13 apareció el 23 de julio y que el 28 de julio el estado volvió de Submitted to IESG for Publication a In WG Last Call. El 11 de septiembre se aceptó el nuevo texto. No consta una publicación RFC.

La comparación de la versión 13 con la 14 revela una modificación corta y concreta. Antes, el algoritmo del servidor describía qué hacer si fallaba la validación DNSSEC. Ahora abarca cualquier resultado que no sea un RRset TLSA validado y enumera cuatro clases. Es una corrección de alcance, no un nuevo protocolo completo.

DANE mira ahora al lado cliente

En el diseño conocido de los RFC 6698 y 7671, el cliente consulta TLSA para evaluar la clave o el certificado del servidor. El borrador de DANCE reutiliza esa confianza DNS para autenticar al cliente.

El servidor anuncia que entiende la extensión propuesta dane_clientid dentro de CertificateRequest. El cliente interesado devuelve el nombre completo del propietario de su TLSA junto al mensaje Certificate. El servidor consulta ese nombre exacto; no inventa otro a partir del puerto o del transporte. El mecanismo exige TLS 1.3 o DTLS 1.3 como mínimo.

Para confiar en la respuesta, el servidor puede validar DNSSEC localmente hasta un ancla configurada, normalmente la raíz, o depender de un resolutor validador conectado de forma segura y exigir el bit AD. Dos decisiones iguales con esos dos caminos no tienen idéntica procedencia. El registro debería indicarlo.

La tabla IANA de extensiones TLS no contiene todavía, en este corte, una asignación visible para dane_clientid. El borrador habla de una futura asignación. No hay base para anunciar un número ni una adopción generalizada.

No todo resultado negativo es un fallo de DNSSEC

Un fallo de validación indica que la evidencia recibida no pudo autenticarse bajo la cadena y las reglas aplicables. Puede requerir una investigación de firmas, claves, tiempo o ruta. No prueba por sí solo un ataque.

Una respuesta no autenticada por zona sin firmar o delegación insegura es otra situación. En ese tramo no existe la obligación de obtener una respuesta autenticada por DNSSEC. El RFC 4033 separa zonas firmadas, zonas sin firma y expectativas creadas por anclas de confianza. Llamar “bogus” a todo lo inseguro destruye esa diferencia.

NXDOMAIN declara inexistente el nombre consultado. NODATA permite que el nombre exista, pero sin un registro del tipo TLSA solicitado. El tratamiento de respuestas negativas del RFC 2308 conserva ese contraste. Un nombre eliminado, un alta incompleta y una ruptura de validación no deberían abrir el mismo ticket automático.

La revisión no atribuye culpabilidad. Un cliente puede usar un nombre antiguo; una zona puede ser intencionadamente no segura; la publicación TLSA puede estar pendiente. El borrador solo define la conducta de interoperabilidad.

Sin embargo, registrar únicamente handshake_failure borra el punto donde acabó la evidencia. También lo borra anotar solo “sesión aceptada sin autenticación”. La disponibilidad aparente no devuelve la causa perdida.

Coincidir y autorizar son dos etapas más

Si llega un RRset TLSA validado, el servidor aún compara su contenido con el certificado o la clave pública del cliente. Los campos de uso, selector y tipo de coincidencia determinan qué comparación procede. Un fracaso ahí conduce a otra elección entre cerrar o tratar al cliente como no autenticado, conforme a la política.

Si la comparación funciona, DANE autentica la identidad en los términos del mecanismo. La aplicación puede aplicar después listas permitidas, dominios autorizados o funciones locales. El propio texto reconoce esas reglas. Un cliente autenticado puede carecer de permiso; una conexión no autenticada puede continuar con permisos muy limitados. Autenticación y autorización no son dos nombres para el mismo resultado.

Por eso hacen falta tres columnas, no una: clase DNS, resultado de la coincidencia DANE y decisión de acceso. Cada una pertenece a un actor y una regla distintos.

Conservar el recibo sin convertirlo en vigilancia

No conviene llenar el intercambio TLS de diagnósticos internos. Los nombres de cliente pueden identificar personas, máquinas o funciones, y el propio borrador reconoce riesgos de correlación. Propongo un recibo de decisión de consulta local y limitado. Es una recomendación editorial, no una exigencia de IETF, DANCE o IANA.

El recibo puede vincular hora; nombre TLSA suministrado en forma autorizada o protegida por hash; tipo de consulta; una de las cuatro clases; estado DNSSEC; validación local o resolutor confiable; referencia de ancla o de política de resolución; versión de la política del servidor; rama elegida; coincidencia del certificado si se alcanzó; y autorización final de la aplicación.

Cuando el flujo se detenga antes, el campo debe decir no alcanzado. No debe convertir NXDOMAIN en una supuesta discrepancia de certificado ni una delegación insegura en un fallo criptográfico. El acceso y el borrado del recibo tienen que seguir la sensibilidad del identificador. Los informes públicos pueden agregar cantidades sin revelar clientes concretos.

El Policy Mirror de Heng Lu exige separar actor, norma y prueba. El operador DNS controla registros y delegación; el cliente propone el nombre; el servidor escoge la vía de validación y su política de TLS; la aplicación concede derechos. La Minimum Initial Specification defiende una regla compartida mínima que no absorba todas las decisiones futuras. La revisión conserva ese reparto. El recibo evita que la decisión local se vuelva inexplicable.

Fuentes

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Historial del documento
  3. Revisión 13
  4. Revisión 14
  5. Grupo de trabajo DANCE
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — operaciones DANE
  8. RFC 2308 — caché negativa de DNS
  9. RFC 4033 — introducción a DNSSEC
  10. Registro IANA de ExtensionType TLS
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification