FYI to TLS WG members, as this was not CCed to TLS.
---------- Forwarded message ---------
From: Eric Rescorla <[email protected]>
Date: Mon, Dec 15, 2025 at 10:23 AM
Subject: Re: Last Call: <draft-ietf-dance-client-auth-09.txt> (TLS Client
Authentication via DANE TLSA records) to Proposed Standard
To: <[email protected]>
Cc: <[email protected]>, <[email protected]>, <
[email protected]>, <[email protected]>, <
[email protected]>
I reviewed draft-ietf-dance-client-auth-09.txt and
draft-ietf-dance-clientid-07.txt.
Unfortunately, they both have a number of significant issues, mostly
from a TLS perspective, which preclude them being published in its
current form. I apologize for catching these so late, but it does not
appear that these documents were sent to TLS-WG prior to being sent to
IETF LC, so this is the first time I am reviewing these.
# TLS 1.2 is Frozen
draft-ietf-dance-clientid-07 registers a new TLS extension, but with
the approval of draft-ietf-tls-tls12-frozen-08, the extension registry
is frozen.
No TLS registries [TLS13REG] are being closed by this document.
Rather, this document modifies the instructions to IANA and the TLS
Designed Experts to constrain what type of entries can be added to
existing registries. x2
...
All other TLS registries should have this Note added to them: Any
TLS entry added after the IESG approves publication of {THIS RFC}
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like
"For TLS 1.3 or later" in that entry, such as the "Comment"
column.
Therefore, this draft should only be defining a new extension for TLS
1.3. The remainder of this document will refer only to the TLS 1.3
binding.
# Revealing the Client's Identity
In TLS 1.3, the client's certificate is encrypted, but then this
document explicitly asks the server to look up the TLSA record
for the client's identity in the DNS in S 7.
* 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.
* Look up the TLSA record set in the DNS. The response MUST be
cryptographically validated using DNSSEC. The server could
perform DNSSEC validation itself, authenticating the full chain
back to a configured trust anchor (normally the DNS root).
Alternatively, it could also be configured to trust responses
obtained via a validating resolver to which it has a secure
connection, by requiring the Authenticated Data (AD) bit to be set
in the responses. If DNSSEC validation fails, the server MUST
treat the client as unauthenticated.
This has the effect of revealing the client's identity on the wire.
Although the connection identifier is not provided, as a practical
matter an observer can determine this from timing. As far as I can
tell, there is no technical reason for this design; instead the client
should supply its DANE information as a Certificate extension
(permitted in TLS 1.3). This will then be encrypted.
# Cross-Protocol Attacks
S 2.1 of client-auth contemplates that the client might have multiple
identities
corresponding to different applications. If these services have the
same public key, it appears that an attacker could mount a
cross-protocol attack there traffic is redirected from one service to
another.
Arguably, this attack already exists if the server uses the same
identity for both protocols, but it seems possible that there might be
a setting in which this was inferred solely from something like the
client IP address. In any case, it seems like it would be better for
the service identifier to be included in the transcript.
# Indicating Certificate Presence
Section 2 of client-auth states:
which one the server should use. An additional situation in which
this extension helps is where some TLS servers may need to
selectively prompt for client certificate credentials only for
clients that are equipped to provide certificates.
However, that doesn't work with TLS 1.3 if the server send sthe
extension in CR, because CR appears first. Instead, you want
something in CH, like
https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/.
# Other Comments
## ClientAuth
S 7.
A TLS Client conforming to this specification MUST have a DNSSEC
[RFC9364] signed TLSA record published corresponding to its DNS name
and X.509 certificate or public key. The client presents this
certificate or public key in the TLS handshake with the server. The
client should not offer ciphersuites that are incompatible with its
certificate or public key.
I don't understand what this text means. Client authentication algorithms
in TLS are effectively orthogonal to cipher suites.
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.
* Request a client certificate in the TLS handshake (the "Client
Certificate Request" message). This could be done
unconditionally, or only when it receives the TLS DANE Client
Identity extension from the client.
* If the client has sent a non-empty DANE Client Identity extension,
then extract the client's domain name from the extension.
Otherwise, extract the client identity from the Subject
Alternative Name extension's dNSName type.
You seem to be skipping a step here where the client supplies its
certificate in the TLS handshake.
* 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.
Below you say that the client MUST supply the client identity
extension if there are >1 SANs but what is the server to do
if the client does not?
## ClientId
S 3.
The DANE Client Identity Extension type, "dane_clientid", will have a
value assigned and registered in the IANA TLS Extensions registry.
Its extension data (if not empty) has the following format:
opaque ClientName<1..2^8-1>;
This is sort of an unusual structure for the extension where we have
to see if it's nonzero-length in order to then check the length of the
extension. I would instead have the lower bound of ClientName be 0,
and use that to indicate no name is present.
The wire format of a domain name is limited to 255 octets. In
keeping with the practice of most TLS extensions, this extension
specifies the use of the textual presentation format of domain names
instead. In theory, the presentation format can exceed 255
characters because it allows the expression of any arbitrary octet
with the "\DDD" sequence of characters (where DDD is the decimal
value). Applications using this extension (and the DANE TLSA Client
Authentication protocol more generally) should ensure that client
domain names being used do not need to resort to the \DDD syntax by
limiting the alphabet suitably, such as only allowing letters,
digits, hyphens, and underscores. This ensures that the presentation
format client domain name will comfortably fit within the 255 octet
limit.
Why not just allow 2^16-1?
On Tue, Dec 9, 2025 at 8:53 AM The IESG <[email protected]> wrote:
>
> The IESG has received a request from the DANE Authentication for Network
> Clients Everywhere WG (dance) to consider the following document: - 'TLS
> Client Authentication via DANE TLSA records'
> <draft-ietf-dance-client-auth-09.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email protected] mailing lists by 2025-12-23. Exceptionally, comments
> may
> be sent to [email protected] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> The DANE TLSA protocol describes how to publish Transport Layer
> Security (TLS) server certificates or public keys in the DNS. This
> document updates RFC 6698 and RFC 7671. It describes how to
> additionally use the TLSA record to publish client certificates or
> public keys, and also the rules and considerations for using them
> with TLS.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-dance-client-auth/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
