IETF Last Call Review of draft-ietf-dance-client-auth-09
review-ietf-dance-client-auth-09-dnsdir-lc-brown-2025-12-22-00

I'm the designated dnsdir reviewer for this draft which details how TLS servers
can use TLSA RRs associated with the name of a connecting client to
authenticate whether the client certificate presented should be trusted or not.

The draft is short, clear, and mostly unproblematic, but I am concerned there
is an issue with the specification of the names client TLSA records are to be
used with - specifically they are under specified in general and further the
examples given appear to conflict with RFC8552 underscored node name
registration requirements.

My understanding is this draft is part of the DANCE WG outputs and sits within
a broader framework of changes described in the referenced DANCEARCH draft.

On the surface the draft simply adds an additional use for TLSA records, no
changes to their format are proposed, simply their use on new (client
associated) names. This adds a reasonable level of additional complexity to the
overall DANE landscape and TLS authentication semantics, but I'm not qualified
to comment on that... so from a purely DNS perspective this re-use of TLSA
records to provide client authentication information seems reasonable.

The major issue I see is the lack of specification for what those new client
names should be or how they are constructed. S2 states: "This document thus
does not proscribe a single format, but mentions a few that may have wide
applicability."

In addition to the general ambiguity this leaves, the two examples given appear
to propose or envisage the use of client TLSA records with hostnames containing
underscore prefixed labels (e.g. _devices, _SERVICE) that are not (as far as I
can find) present in the "Underscored and Globally Scoped DNS Node Names"
registry[0] or proposed to be registered there by any of the associated DANCE
drafts. This makes the example names conflict with RFC8552 (as I understand it)
as it requires (S2):

 "If a public specification calls for use of an underscored node
      name, the global underscored node name -- the underscored name
      that is closest to the DNS root -- MUST be entered into this
      registry."

I do not see the section 2.2 example of _devices in the registry, and section
2.1 proposes that the _SERVICE labels could be either a custom string, or a
service name from the IANA Service Name Registry [SRVREG] - but none of these
such service names are registered for use as underscored DNS node names either,
and obviously a custom service name is not going to be registered either.

Therefore it seems to me that before this draft can proceed further
clarification of the hostnames expected to be used with client TLSA records and
how such names comply with the requirements of RFC8552 needs to be added.

[0]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names