Summary

  • draft-ietf-dance-client-auth-14 lets a TLS 1.3 client send the complete owner name of its TLSA record, after which the server validates the DNSSEC answer and matches the record to the presented certificate or raw public key.
  • A successful match authenticates a bounded name-to-key statement. Server allowlisting, application permission, assignment freshness and the result of any requested operation still need their own evidence.

The decisive moment in the proposed protocol happens before the application sees a request. A TLS client receives a CertificateRequest containing an empty dane_clientid extension. It returns its certificate—or a raw public key—with the same extension populated by a complete TLSA owner name. The server queries exactly that name, validates the answer through DNSSEC and checks whether at least one TLSA record matches the key material in the handshake.

If those steps succeed, something important has been proved. The peer that completed the handshake controls the private key corresponding to a DNS-published TLSA association at the asserted owner name, under the certificate-usage rules selected by that record. The proof can remove a certificate-authority dependency in DANE modes or add a DNS constraint to PKIX modes. It can also give raw public keys a name that no certificate carries.

What it has not proved is equally important. The record does not tell the server that the expected employee still owns the account, that a sensor remains assigned to the same customer, that a workload may enter this tenant, or that the application may execute the requested operation. Revision 14 says servers may apply their own allowlisting and authorization rules. That sentence is not a footnote to authentication. It is the line between a cryptographic receipt and an operational decision.

A live second Last Call, not a settled standard

The current text is revision 14, dated 11 September 2026. The IETF Datatracker lists it as an active DANCE Working Group Internet-Draft intended for Proposed Standard. On 15 September the IESG opened a second IETF Last Call, explaining that the draft combines the earlier client-identity and client-authentication work. Comments are due 29 September.

The review record remains mixed. The Security Directorate review marked revision 14 Ready, with minor requests about extension error handling and explaining the raw-public-key binding. The DNS Directorate review marked it Not ready. Its central objection is that the proposed _service and _device owner-name formats do not yet satisfy the underscored-node registration rule in RFC 8552; it also questions the presentation-format and 255-octet explanation for ClientName.

These are active review comments, not editorial problems that can be wished away. The IESG has not approved the draft, the extension value is still requested as TBD, and the proposed IANA registration would say Recommended=N because the mechanism has specific use cases. Nothing in the public record proves deployment or conformance by a named product.

The server queries the name the client supplies

Server-side DANE normally derives a TLSA owner name from a service's transport coordinates. Client identities do not share one universal naming convention. Revision 14 therefore makes the client send the full owner name and tells the server not to construct anything further. The draft illustrates a service-specific form, a device form and a freeform DNS name, while leaving application naming policy outside the TLS layer.

That division is efficient but consequential. The extension proves what string entered the handshake; DNSSEC proves the returned DNS data under a validation chain. Neither establishes what the label means socially or administratively. A name might denote a person, a device, a fleet role, a mailbox, a workload or a service-specific credential. Its meaning comes from the authority that assigned and maintains the namespace.

The server's DNS work is precise. It must obtain a DNSSEC-validated TLSA RRset, either by validating to a configured trust anchor or by securely relying on a validating resolver and its Authenticated Data bit. An unsigned answer, an insecure delegation, a DNSSEC failure, NXDOMAIN or NODATA is not an authenticated TLSA set. Policy then decides whether to abort with handshake_failure or continue while treating the client as unauthenticated.

Successful matching also has several forms. With DANE-EE usage 3, the certificate or public key is matched directly and the DNS name need not appear in the certificate. With DANE-TA usage 2 and PKIX usages 0 or 1, the conveyed name must also appear as a dNSName Subject Alternative Name and be verified as a reference identity under RFC 7671. Raw public keys use DANE-EE with the SPKI selector described by RFC 7250. These branches change the evidence required for authentication; none turns authentication into application authority.

The missing receipt is local policy

Suppose a server validates _control.device7.example and matches the TLSA record to the presented key. A useful audit can now preserve the ClientName, DNS answer, validator, trust anchor, TTL, TLSA usage, selector, matching type and certificate or SPKI fingerprint. The audit still cannot infer four later facts.

First, assignment may be stale. DNS TTL, key rotation, certificate revocation, asset reassignment and account termination follow different clocks. A valid cached TLSA answer may coexist with an HR or device-management decision that removed the subject's authority.

Second, the server may authorize only a subset of names or domains. Revision 14 expressly leaves that allowlist to server policy. A cryptographic match can be valid while the local policy rejects the client.

Third, a TLS session can be accepted before an application evaluates tenant, resource, action, transaction value or workflow state. Transport authentication cannot substitute for the application's authorization check.

Fourth, permission is not outcome. An allowed request may fail validation, lose a race, time out, roll back or be rejected by a downstream system. Only the application's commit record and an independently observed effect can close that final gap.

Privacy exposure is another boundary, not an incident verdict

TLS 1.3 encrypts the client's Certificate message, but the server then looks up the asserted client name in DNS. Without encrypted DNS, that query may expose a human- or machine-associated name to parts of the resolution path. RFC 9156 query-name minimisation can reduce what higher layers see, and encrypted resolver and authoritative transports can reduce disclosure further.

The exposure should be logged and assessed, especially for human-linked names. It should not be promoted into proof of compromise. A resolver log shows that a name was queried, not who ultimately used the key, which application action followed or whether an adversary exploited the observation.