Summary

  • draft-ietf-dance-client-auth-14, uploaded on 11 September, remains an Internet-Draft in Working Group Last Call. It is not an RFC or an approved standard.
  • Revision 14 explicitly routes four results other than a DNSSEC-validated TLSA RRset—validation failure, an unauthenticated answer, NXDOMAIN and NODATA—into the same server choice: abort, or treat the client as unauthenticated when policy allows.
  • A compact lookup-decision receipt should retain the DNS result class, validation and trust mode, policy version and later authorization outcome. This is an editorial control proposal, not a new IETF requirement.

One paragraph changed the evidence boundary

The Datatracker dates revision 14 of “TLS Client Authentication via DANE TLSA records” to 11 September 2026. The document belongs to the active DANCE Working Group in the IETF Security Area. Its intended status is Proposed Standard, but its recorded state is still Working Group Last Call with document-shepherd follow-up underway. The IESG state says Waiting for AD Go-Ahead::AD Followup. These are process coordinates, not an approval notice.

The history matters because most of revision 14 is unchanged. Revision 13 arrived on 23 July. On 28 July, the document moved from Submitted to IESG for Publication back to In WG Last Call. Revision 14 was uploaded on 11 September. Its consequential edit is a short expansion in the server-behaviour algorithm.

Revision 13 covered the case where DNSSEC validation failed. Revision 14 instead covers any result other than a DNSSEC-validated TLSA RRset, then lists examples. A validation failure is one. An unauthenticated answer caused by an unsigned zone or insecure delegation is another. NXDOMAIN and NODATA are the third and fourth.

The mandatory fork is shared. The server must abort with a TLS handshake_failure, or, if its policy permits, treat the client as unauthenticated. The protocol text has become more precise about what arrived from DNS while leaving the final choice local.

DANE is being turned around

RFC 6698 and RFC 7671 describe the familiar direction of DANE: a TLS client looks up a server’s TLSA records and uses authenticated DNS data when evaluating the server certificate or key. The DANCE draft adapts the mechanism to the other side of the connection.

A supporting server advertises the proposed dane_clientid extension in its CertificateRequest. A participating client replies in its Certificate message with the full owner name of its TLSA record. The server does not derive a name from a port and transport tuple. It queries the exact name supplied by the client, authenticates the DNS answer, evaluates the TLSA data against the presented certificate or public key, and only then applies any independent allowlisting or authorization rules.

That sequence requires TLS 1.3 or DTLS 1.3 or later. It also puts a DNS decision inside a security-sensitive handshake path. The server can validate DNSSEC itself back to a configured trust anchor, normally the DNS root. Or it can rely on a validating resolver reached through a secure connection and require the AD bit. The selected trust mode is therefore part of the evidence for whatever decision follows.

The draft’s proposed extension has not yet appeared as an assigned value in the IANA TLS ExtensionType registry at this research cutoff. The draft itself uses future-tense allocation language. That is another reason to report a live document revision, not an imaginary deployment.

Four negative results do not say the same thing

The new list prevents a common analytical error: treating every missing validated RRset as “DNSSEC failed.” Each class describes a different point in the chain.

A DNSSEC validation failure says the server or trusted resolver could not validate what it received under the applicable security chain. It can reflect bad or unusable authentication evidence. The draft does not turn that observation into a diagnosis of attack or fault.

An unauthenticated answer because a zone is unsigned or a delegation is insecure says the chain does not require authenticated data at that point. That is not the same as receiving signed data that fails validation. RFC 4033 keeps signed zones, unsigned zones and trust-anchor expectations distinct for exactly this reason.

NXDOMAIN says the queried owner name does not exist. NODATA says the name can exist while the requested TLSA type does not. RFC 2308 established the negative-caching treatment behind that distinction. An operator may investigate an absent device identity differently from an existing identity name with no TLSA record.

None of these observations proves malice. A client may offer a stale name. A delegation may intentionally be insecure. A record may not yet have been provisioned. A signature chain may be broken. The protocol correctly avoids encoding an incident verdict into the TLS response.

Yet the observations are not interchangeable. If the visible log records only handshake_failure, four different causes have been flattened into one result. If it records only “unauthenticated client allowed,” the same loss occurs behind a successful connection. The policy can be legitimate while its audit trail becomes too coarse to explain it.

The second fork comes after the first

Receiving a DNSSEC-validated TLSA RRset does not complete the decision. The server still has to use the record’s certificate-usage, selector and matching fields against the client certificate or raw public key. If matching fails, the draft again permits abort or unauthenticated treatment according to server policy. Multiple records can succeed when at least one usable record matches, subject to the operational rules in RFC 7671.

Even a successful DANE authentication is not a grant of application access. The draft expressly leaves servers free to apply allowlists and authorization rules—for example, accepting only identities within selected domains. A client can therefore be DNS-authenticated and still unauthorized. Conversely, a connection that continues as unauthenticated may reach only a public or restricted surface; the word “continues” does not mean “admitted to everything.”

The useful state model has at least three boundaries: DNS result, DANE certificate or key match, and application authorization. Combining them into one success flag would erase which authority made which decision.

Keep a lookup-decision receipt

The draft need not carry an operational case file inside TLS. Raw DNS names can identify people or devices, and its security considerations already warn that client identities can create privacy exposure. The missing evidence belongs in a bounded local record. I call it a lookup-decision receipt. It is an editorial proposal, not an IETF, IANA or DANCE requirement.

For each material decision—or a privacy-preserving sample—the receipt can bind the observation time; a protected hash or authorized form of the client-supplied TLSA owner name; query type; one of the four result classes; the DNSSEC validation state; whether validation was local or delegated to a protected resolver; the trust anchor or resolver-policy reference; the server-policy version; the branch taken; whether certificate matching was reached and its result; and the final application-authorization state.

The record should say not reached where a prior branch ended processing. It should not invent a certificate mismatch after NXDOMAIN, or call an unsigned answer bogus. Retention and access should match the sensitivity of client identity data. An aggregated public report can expose class counts and policy changes without publishing device names or connection histories.

Heng Lu’s Policy Mirror provides the right test: name the actor, the governing rule and the evidence that supports the state. Here the DNS operator controls signed delegation and records, the client asserts an owner name, the server selects a validation path, local policy selects the TLS branch, and the application decides authorization. The Minimum Initial Specification suggests keeping the shared rule narrow enough to preserve local choice. Revision 14 does that. The receipt preserves evidence without moving the policy decision back into the protocol.

The revision is valuable because it names observations that an earlier sentence compressed. Operations should not compress them again after the handshake.

Sources

  1. IETF Datatracker — draft-ietf-dance-client-auth-14
  2. Datatracker document history
  3. Immutable revision 13
  4. Immutable revision 14
  5. DANCE Working Group
  6. RFC 6698 — DANE TLSA
  7. RFC 7671 — DANE Operations
  8. RFC 2308 — DNS Negative Caching
  9. RFC 4033 — DNSSEC Introduction and Requirements
  10. IANA TLS ExtensionType Values
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification