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

[Eric Rescorla <[e-mail]>]

On Mon, Jan 26, 2026 at 8:39 AM Shumon Huque <[e-mail]> wrote:

> 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.
>

As I said in my previous response, TLS 1.3 already. protects the client's
certificate,
so you're introducing a privacy regression. The situation is entirely
different with
the server's identity.


>
> > 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.
>

The discussion of barriers to implementation might be more productively had
in reference to some specific deployment scenario. Who is presently planning
to deploy this and in what settings. Would this be an obstacle to them
deploying?

 Especially in cases where hiding the client identity for the application
may not be that important (like a warehouse full of machine identities).

We generally don't design security mechanisms for this kind of limited scope
deployment, at least without a very prominent limited applicability
statement.
I would observe that the DANCE architecture document makes quite
expansive applicability claims which would clearly be in tension with this
kind of limitation.

Careful use of encrypted DNS resolvers can also mitigate this and could be
> a recommendation.
>

"Careful" is doing a lot of work here, given that we don't really have any
kind
of generally applicable mechanism for securely determining an encrypted
resolver, let alone protecting recursive to authoritative.

-Ekr




> > 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.
>
>