[TLS] Re: Last Call: <draft-ietf-dance-client-auth-09.txt> (TLS Client Authentication via DANE TLSA records) to Proposed Standard

[Shumon Huque <[e-mail]>]

On Mon, Jan 26, 2026 at 10:56 AM Salz, Rich <[e-mail]> wrote:

>
>
>    - > 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.
>
>
> A client looking up SVCB records does not expose the client’s identity.
> EKR pointed out that this doc explicitly has the server look up the client
> identity.
>

Yes, I was speaking about the general topic of not revealing domain name
identities on the wire (for client or server). TLS 1.3 wants to do both.

> 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.
>
> I think you should. A key point of TLS 1.3 is not to expose the client
> identity.
>

Ok, I'm pondering this topic. Requiring the client to implement a complex
DNSSEC chain extension like mechanism will likely be a significant barrier
to implementation I feel. Especially in cases where hiding the client
identity for the application may not be that important (like a warehouse
full of machine identities). Careful use of encrypted DNS resolvers can
also mitigate this and could be a recommendation.

> As a bare minimum, if no changes are made, the security considerations
should make this exposure explicit.

Ack.

>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.
>
> That seems like a good idea.
>
> >> 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).
>
> You probably do not want a custom alert as that gives out too much
> information.
>

Good point.

Shumon.