[Dance] Re: draft-ietf-dance-client-auth-09 ietf last call Secdir review

[Shumon Huque <[e-mail]>]

> On Tue, Dec 16, 2025 at 12:53 PM Mike Ounsworth via Datatracker <
[e-mail]> wrote:
> Document: draft-ietf-dance-client-auth
> Title: TLS Client Authentication via DANE TLSA records
> Reviewer: Mike Ounsworth
> Review result: Serious Issues

Sorry for my belated reply. I'm making some updates to the draft based
on your review, but I'll respond in email first ...

> I feel that this document has two major issues:
>
> It’s a mixture of specifying the syntax of a new DNS record type, and
modifying
> the behaviour of the TLS handshake, all in the same document. I feel like
it
> would be cleaner to chop this document down to a 2-pager that just
specifies
> the new DNS record, and move all the TLS modifications into
> draft-ietf-dance-tls-clientid so that they are all in one place. I don’t
love
> splitting TLS handshake behaviour changes over two documents. This
document
> keeps referring to “the SAN of type dNSName”, but of course a cert can
have any
> number of SANs. I can’t tell if this is a technical issue (and if so,
it’s a
> fundamental one, complete with interop and security problems), or merely a
> presentation issue.

It isn't actually specifying the syntax of a new DNS record type. It
documents how to use an existing DNS record type ("TLSA", documented in
RFC 6698) for TLS client authentication. It does give recommendations
for where to place the DNS record (the "owner name") for some example
applications, but that is not specifying new syntax, or defining a new
record.

I certainly agree that it would be better to combine the client-auth
and  tls-clientid drafts, so that all the TLS protocol enhancements are
in one place. The original reason for this split was that the client
auth doc was being discussed many years ago in the (now defunct) DANE
working group, and it was thought that TLS extensions (like dane-clientid)
would need to go through the TLS working group. Ultimately, that did not
turn out to be the case. When this work (several years later) re-appeared
in secdispatch, the recommendation was to put all the work into its own
new working group. But the document split remained.

So, if there is agreement, I think combining the dance-client-auth and
the tls-clientid draft would be good. I don't think it's good idea to
additionally split out the TLSA record details into a separate draft, as
that would be a very small draft that wouldn't make much sense without
the client auth draft.

> Way down in section 7 there is this sentence, which might actually be the
most
> critical sentence of the entire document because it changes the
interpretation
> and error-handling of almost every other sentence.
>
> “If the presented client certificate has multiple dNSName identities,
then the
> client MUST use the TLS DANE client identity extension to unambiguously
> indicate its intended name to the server.”
>
> I would like the authors to move this up to “Section 3: Authentication
Model”
> and expand it into a whole section. I suggest something like:
>
> “””
> 3.1 Resolving Multiple Identifiers
>
> A client device performing DANE client authentication MUST present a
single
> DANE identifier to the server for validation and binding to the TLS
session.
> This is accomplished via one of the two following mechanisms:
>
> Sending TLS ClientHello containing a single DANE Client Identity TLS
extension
> [TLSCLIENTID] signalling which DANE identifier to use for the TLS
session, or
> Responding to a TLS CertificateRequest message with a client certificate
that
> contains exactly one Subject Alternative Name extension of type dNSName.
>
> Implementations MUST NOT perform multiple DANE Client Identifier
validations in
> a single TLS connection. “””
>
> I think I’m getting well beyond the scope of this document, and into the
scope
> of draft-ietf-dance-tls-clientid (which I have not read), but I can
imagine
> situations where client devices are provisioned with multiple DANE client
> identities for fall-back reasons … are you sufficiently specifying which
TLS
> alerts to use in all the DANE error cases so that the server can indicate
that
> DANE authentication failed and the client should try again with a
different
> DANE identifier?

We can add the section you proposed on Resolving Multiple Identifiers.

To your earlier comment, yes, the DANCE working group understands that
there can be multiple dNSName SANs in a certificate.  This document
currently recommends that for DANE client authentication, there should
be only one, and if there are multiple, then the dane-client-id extension be
used to precisely indicate which one to use - to simplify processing on the
TLS server, otherwise the server would have to do multiple DANE/DNSSEC
authentications inline in the handshake, one for each domain name identity,
which could impose an unnecessary performance cost.

This topic has been discussed in the past in DANCE, and the fallback
scenario you envision did not seem important to the various DANE application
use cases under discussion. If needed, I think the way this could be
supported is by having the TLS client could follow-up with a new TLS session
with a new TLS dane clientid extension.

> Once a section like that is added that makes it clear that we will always
have
> a unique DANE identifier per TLS session; I would like the authors to do
a pass
> over the document paying attention to every sentence that’s “the DANE
> identifier”, or “the dNSName SAN”, or “the TLS DANE Client Identity TLS
> extension” and make sure that there are no ambiguities or error-handling
cases
> that need to be specified.

Ok.

>
> Alternatively, I feel like the authors could respond to my SECDIR review
by
> deleting half the document and shortening it to a 2-pager "Here's the
syntax of
> the new DNS record type -- see related docs for how to use this within a
TLS
> session".
>
> Either way, I would like to do another SECDIR review after the authors
have
> posted a new version.

Can you comment on my proposal (and rationale) for just combining
the 2 drafts, and leaving in the DNS record usage description (and
possibly making it more clear that this is not defining a new DNS
record).


> —---
> I include below comments of a less serious nature.
>
> The draft contains a lot of RFC 2119 terms in lower-case. Many of these
feel
> like they should be normative (ie upper-cases), or the sentence should be
> re-written to use a different word. The draft also contains some normative
> sentences that don’t contain a RFC 2119 term, but probably should, such
as: “””

Thanks, from a quick glance I think you're right. We'll make a pass through
and review those potential keywords and update where needed.

> 8. Raw Public Keys When using raw public keys in TLS [RFC7250], this
> specification requires the use of the TLS DANE Client Identity
extension.”””
>
> If a presented client cert contains multiple dNSName SANs, and only one
has
> been DANE-validated, how is this communicated to the application layer so
that
> it knows which SAN has been validated, and therefore is more trustworthy?
> (again, this probably belongs in draft-ietf-dance-tls-clientid and not in
this
> document, but the fact that I’m thinking about it might indicate that
there’s
> actually too much overlap between the two documents, and this TLSA Record
doc
> should be simplified down to just the DNS record stuff).

Yes, the answer is that it is the dns name that is specified in the
dane-client-id extension. And we've already agreed now that these
drafts should be combined.

> “In this document, the term TLS is used generically to describe both the
TLS
> and DTLS (Datagram Transport Layer Security) [RFC6347] protocols.”
>
> Also QUIC?

Yes, we should mention QUIC too.

> Draft-friel-pki-for-devices-00 expired in 2018 without having been
adopted. Are
> you sure this is a good motivating usecase? Your Format 2 is probably
fine even
> if you delete this sentence that references the long-expired draft.

Yes, best to just delete the reference to that obsolete document.

> Section 3. Authentication Model
>
> “The client is assigned an identity corresponding to a DNS domain name.
This
> domain name doesn't necessarily have any relation to its network layer
> addresses. Clients often have dynamic or unpredictable addresses, and may
move
> around the network, so tying their identity to network addresses is not
> feasible or wise in the general case.”
>
> You’re telling me about the negative – the relationships that might or
might
> not be present. I would rather that you tell me about the positive
properties
> that you are assuming about this DNS-name-to-Device binding. For example,
you
> assume that this is a stable identifier (define “stable” … lifetime of the
> device? At least stable enough that you’re not spamming the DNS with
updates?),
> the client knows its own name, the name is unique to the client device (ie
> multiple devices don’t share the same name / keypair, or is that allowed?
A
> MUST / SHOULD / MAY would be appropriate here), the name is under some
sort of
> authoritative namespace for the device … I haven’t yet read all the DANCE
docs,
> but I assume that the verifier cares not only that the client has a DANCE
DNS
> record, but that it has one under a domain that the verifier expects. Are
there
> any other properties that are assumed about the name that are worth
mentioning
> here?

The "talk about negatives" was put in the document after having to
explain multiple times to some folks in the SMTP transport community
why the domain name associated with the SMTP client's network address
was not a good candidate for the client identity. I would probably be
inclined to take it out at this point.

Yes, the name is expected to be stable for the clients. I'll see if I
can remove the negatives and enumerate the actual properties more
clearly.

> “Where client certificates are being used, the client also has a
certificate
> binding the name to its public key.”
>
> Probably worth at least a short mention here about what assumptions (if
any)
> are made about the trust chain of this cert. For example, are self-signed
certs
> allowed here, and if so, does that change the authentication model at all?

Ok. The DANE authentication model (via the usage parameter) supports
self signed certificates, domain managed CA issued certs (CA key
specified in DNS), as well as the PKIX constraining modes. None of
those modes are precluded by this draft, though we expect the pure
DANE modes to be most commonly used.

>
> Section 4 Client Identifiers in X.509 certificates
>
> “If the TLS DANE Client Identity extension (see Section 5) is not being
used,
> the client certificate MUST have have the client's DNS name specified in
the
> Subject Alternative Name extension's dNSName type.”
>
> Typo: “have have”

Ack.

> Something about this wording feels incomplete to me. There will be one
DANE
> identifier designated for the TLS session, but that doesn’t mean that
there’s
> only one dNSName SAN in the cert.
>
> I suggest a re-word:
>
> “If the TLS DANE Client Identity extension (see Section 5) is not being
used,
> the client's DNS name as used in DANCE MUST appear in the client
certificate in
> a Subject Alternative Name extension of type dNSName type. A client
certificate
> MAY contain multiple DANE SANs. A client certificate MAY also contain
other
> SANs (including other dNSName SANs) that are not related to DANE.”

Yes, we'll clarify. I think I'm repeating myself now, but if there are
multiple domain
name identified in the certificate, the dane client id extension is used
to distinguish which identity to be used.

> 5. Signaling the Client's DANE Identity in TLS
>
> “The DANE Client Identity TLS extension [TLSCLIENTID] is used for …
> It is also helpful when the client certificate contains multiple
identities,
> and only a specific one has a DANE record.”
>
> This sentence adds to the confusion around the “multiple identity
problem”.
> It’s also helpful (mandatory in fact, according to that sentence in
section 7)
> when the client cert has multiple DANE SANs, which will almost certainly
be the
> case if you’re doing Format 1 (per service) DANE identifiers, or if the
client
> has fallback DANE entries, or DANE entries in multiple DNS zones, etc
etc. I
> think this sentence is adding more confusion than clarity. Again, I would
add a
> sub-section to Section 3 that addresses multiple client identities, and
then
> delete this sentence.

[Skipping as this topic has already been discussed above]

>
>  7. Changes to Client and Server behavior
>
> “The client should not offer ciphersuites that are incompatible with its
> certificate or public key.”
>
> Should that be a SHOULD ?
> Also, TLS 1.3 removed the signing algorithm from the cipher suite for
exactly
> this reason, so this sentence feels antiquated.

Yes, we'll remove this.


> “If the client's certificate has a DANE record with a certificate usage
other
> than DANE-EE, then the presented client certificate MUST have have the
client's
> DNS name specified in the Subject Alternative Name extension's dNSName
type.”
>
> Again, I don’t like “the SAN extension” here because a cert can have
multiple
> SANs. This sentence probably needs a re-structure.

This can be addressed again with reference to the use of TLS extension to
disambiguate which SAN entry. But we'll clean up the text and make it more
precise.

>
> The rest of my comments pertain to “ 7. Changes to Client and Server
behavior”
> which I find is generally under-specified (ie lacking handling of
edge-cases
> and specification of error-handling behaviour). This section is
specifying TLS
> handshake behaviour changes, and I’m not sure that this section belongs
in this
> document at all. I suggest that this entire section be moved to
> draft-ietf-dance-tls-clientid so that all the TLS behaviour modifications
are
> in one place.
>
> Anyway, here are my comments:
>
> “A TLS Server implementing this specification performs the following
steps:”
>
> If these are sequential steps, then maybe it would be better to present
them as
> a numbered list rather than a bullet list?

Yes, numbered would be better.

>
> Step 2: “Otherwise, extract the client identity from the Subject
Alternative
> Name extension's dNSName type.” I’m being pedantic, but what SAN
extension? So
> far in this list of steps, the server has requested a client cert, but you
> haven’t said that the client actually sent one. There’s error handling to
be
> specified between those two steps and I think his section needs to list
the
> error cases exhaustively and specify the error-handling behaviour; like
the
> client just didn’t respond to the Client Cert request, or replied with a
raw
> public key (but without a DANE Client Identity extension), or the client
> responded with a cert that contains multiple dNSName SANs. All of these
should
> fail the TLS handshake; you need to specify that and specify which TLS
ALERT to
> use.

Yes, noted. We need to more exhaustively specify the error handling
for the various cases.


> “Construct the DNS query name for the corresponding TLSA record. If the
TLS
> DANE client identity extension was present, then this name should be used.
> Otherwise, identities from the client certificate are used.”
>
> Again, there’s a plurality problem here “identities from the client
> certificate”, although I think it’s just grammatical; if you specify the
> restrictions properly, then by the time you get to this step, there will
only
> be one identity at play.

[Skipping as already discussed previously]

>
> “If DNSSEC validation fails, the server MUST treat the client as
> unauthenticated.”
>
> This step needs to specify error-handling behaviour, and I’m not
convinced that
> continuing the TLS session as unauthenticated is the right behaviour.
Silently
> dropping a session from “requires authentication” to “unauthenticated”
forwards
> the error-checking to the application layer and feels like the kind of
thing
> that will lead to CVEs. In particular, I believe that here the client
will have
> no way to know whether the session is authenticated or not, and that may
have
> implications for whether it wants to send sensitive information. Wouldn’t
it be
> better to ALERT that the DANE auth failed so that the client can retry
with a
> different DANE identity (or retry without DANE if the client is ok with an
> unauthenticated session).
>
> “Extract the RDATA of the TLSA records and match them to the presented
client
> certificate according to the rules specified in the DANE TLS protocol
[RFC6698]
> [RFC7671]. If successfully matched, the client is authenticated and the
TLS
> session proceeds. If unsuccessful, the server MUST treat the client as
> unauthenticated”
>
> Again, I don’t love silently dropping to unauthenticated.

I don't either. I think Viktor Dukhovni had a stronger argument for this,
to support some mixed mode use cases, and where client authentication was
optional, and the application desired to proceed even if it was specified
and failed. Perhaps this could be configurable behavior rather than MUST
treat the client as unauthenticated.

Shumon.