> On Mon, Dec 15, 2025 at 1:23 PM Eric Rescorla <[email protected]> wrote:
> 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.
Thanks for the review Eric. Yes, we should have looped in the TLS
working group earlier. (I've cc'd them).
> # 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.
Noted.
This draft's origin predated TLS 1.3, and earlier work on it happened when
TLS 1.3 wasn't as widely deployed as it is now.
I would be inclined to just remove TLS 1.2 support from the specification,
if
there is agreement. That would also simplify the description of the TLS
changes quite a bit.
> # 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.
It does, I guess unless encrypted DNS transport is being used.
A number of other protocol mechanisms already have similar problems,
don't they, like TLS client's lookup of SVCB records for ECH, etc, if
not done with encrypted DNS transport.
> 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.
At one point we had considered whether the client should look up
its own DANE information and send it in an extension (the opposite
form of RFC 9102: TLS DNSSEC chain extension), but decided that this
might be too much complexity to impose on the client, particularly since
some of them might be resource constrained. That topic could be revisited.
A hybrid design could be contemplated, where the client looks up and
supplied just its DANE record (and signature, and any associated CNAME/
DNAME chains), and have the server additionally query and validate the rest
of the DNSSEC chain leading up to it.
> # 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.
We could state that those different identifiers should have different
keys. (There might be temptation to use a DNS wildcard to map all
service identities for the same client to a common DANE record with
a common cert/public key, but we could have text that discourages this).
> 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.
Isn't the service identity already included in the transcript by
virtue of it being specified in the dane-client-id extension? We
could also probably shore up the language to mandate the use
of the extension (non-empty), instead of allowing it to be omitted
if the certificate only has one dns SAN identifier.
>
> # 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/.
Yes, this text is a relic of the pre TLS 1.3 version of this document.
I agree that the Request-MTLS flag is a better solution to this
problem. We can reference that.
>
> # 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.
Yes, that was an error. We will remove the last sentence in this paragraph.
>
> 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.
We'll add a bullet for that.
>
> * 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?
The server should abort the connection with an error (and maybe
a tailored TLS alert needs to be defined).
> ## 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.
Ok, that's a good suggestion.
>
> 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?
>
We could.
But the general consensus was that we didn't want to support arbitrary
domain name syntax, and expect that client names would conform to the
typical hostname alphabet. In which case 2^8-1 is sufficient.
Shumon.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
