Resumen

  • draft-ietf-dance-client-auth-14 hace que el cliente TLS 1.3 envíe el nombre propietario completo de su registro TLSA; el servidor consulta ese nombre, valida DNSSEC y compara el registro con el certificado o la clave pública sin procesar.
  • La coincidencia demuestra una relación criptográfica acotada. La asignación de la identidad, la admisión del servidor, el permiso sobre una acción y el resultado necesitan comprobaciones independientes.

Una conexión puede superar una prueba criptográfica impecable y seguir sin tener derecho a hacer nada. Esa es la frontera central del borrador. El servidor anuncia que entiende dane_clientid en CertificateRequest. El cliente devuelve la extensión con el nombre completo que posee su TLSA. El servidor pregunta exactamente por ese nombre; no añade puerto, transporte ni otra construcción.

Si la respuesta TLSA está validada por DNSSEC y alguno de sus registros coincide con el certificado o la clave pública presentados, el par ha demostrado control de la clave privada correspondiente. Pero el resultado no explica si el nombre sigue asignado al mismo equipo, persona o cuenta. Tampoco incorpora la lista de clientes permitidos por el servidor ni la política que autoriza una acción concreta dentro de la aplicación.

Un borrador en segunda consulta

La fuente vigente es la revisión 14, del 11 de septiembre de 2026. El Datatracker la identifica como Internet-Draft activo del grupo DANCE, con destino Proposed Standard. El IESG abrió el 15 de septiembre una segunda IETF Last Call que termina el 29. No es un RFC aprobado ni una política obligatoria.

El expediente muestra una discrepancia material. La revisión de seguridad quedó en Ready con comentarios menores sobre errores de extensión y la explicación de las claves públicas sin certificado. La revisión DNS quedó en Not ready. Sostiene que los formatos _service y _device no cumplen el registro de nombres con guion bajo del RFC 8552, y que el límite de ClientName mezcla de forma confusa formato textual y longitud en wire format.

El valor de la extensión aún figura como TBD. La inscripción propuesta en IANA sería Recommended=N por tratarse de casos específicos. Ninguno de esos pasos equivale a despliegue.

Lo que valida cada capa

El borrador contempla nombres específicos de servicio, identidades de dispositivo y nombres libres. La elección pertenece a la aplicación. DNSSEC valida datos de DNS bajo una cadena; no aporta por sí solo el significado humano u organizativo de una etiqueta. Para conocerlo hay que identificar quién asignó el nombre, bajo qué reglas y si la asignación sigue vigente.

El servidor debe validar el RRset TLSA hasta un trust anchor configurado o confiar en un resolvedor validador conectado de forma segura y en su bit AD. Una respuesta sin firma, una delegación insegura, un fallo DNSSEC, NXDOMAIN o NODATA no producen un conjunto autenticado. La política decide si se aborta o si el cliente queda sin autenticar.

Con DANE-EE 3, el certificado o la clave se comparan directamente y el nombre no tiene que aparecer en el certificado. Con DANE-TA 2 y PKIX 0/1, ClientName también debe coincidir con un dNSName en Subject Alternative Name según el RFC 7671. Las claves públicas sin certificado usan el marco del RFC 7250. Son rutas distintas hacia una prueba de autenticación, no hacia una decisión de negocio.

De la clave al efecto hay varias decisiones

Un registro de auditoría debería conservar por separado el ClientName, la consulta y TTL de DNS, el validador y trust anchor, los campos TLSA, la huella del certificado o SPKI, la política de asignación del nombre, el estado del dispositivo o cuenta, la versión de la allowlist, la decisión de aplicación y el efecto observado.

Un TLSA en caché puede seguir válido después de reasignar un dispositivo. El servidor puede autenticar la clave y rechazar el dominio. La aplicación puede admitir la sesión y negar una operación entre tenants. Una acción autorizada puede fallar, caducar o revertirse. La frase “cliente autenticado” no debe borrar esas transiciones.

También hay un coste de privacidad. TLS 1.3 cifra el mensaje Certificate, pero el servidor resuelve después el nombre en DNS. Sin DNS cifrado, partes de la ruta pueden observarlo. La minimización del nombre de consulta del RFC 9156 reduce exposición. Una consulta observada no demuestra compromiso ni explotación.