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

[Paul Wouters <[e-mail]>]

On Mon, Jan 26, 2026 at 1:37 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Jan 26, 2026 at 10:23 AM Paul Wouters <[e-mail]>
> wrote:
>
>>
>> On Mon, Jan 26, 2026 at 12:59 PM Eric Rescorla <[e-mail]> wrote:
>>
>>>
>>> Taking a step back from the point-by-point responses below.
>>>
>>> The general argument you seem to be offering is that DANCE is intended
>>> for a very limited set of use case where concealing the client's
>>> identity is not really relevant, and therefore it's not a problem
>>> if we leak that identity in the protocol. I don't agree with that
>>> for three distinct reasons.
>>>
>>> First, neither the charter nor the WG documents suggests that
>>> this protocol is designed for a limited set of use cases. To
>>> the contrary, the charter is quite expansive, listing:
>>>
>>>    In response to the challenges related to ambiguity between
>>>    identically named identities issued by different CAs, application
>>>    owners frequently choose to onboard client identities to a single
>>>    private PKI with a limited CA set that is specific to that
>>>    vertical. This creates a silo effect where different parts of large
>>>    deployments can not communicate. Examples of where DANCE could be
>>>    useful includes SMTP transport client authentication,
>>>    authentication of DNS authoritative server to server zone file
>>>    transfers over TLS, authentication to DNS recursive servers, and
>>>    Internet of Things (IoT) device identification.
>>>
>>> This is actually quite a broad scope
>>>
>>
>> I find it actually quite a narrow scope. It clearly indicates a trust
>> model where the WebPKI cannot be used,
>> and private CAs come into play. Instead of needing to specify private
>> CA's as trust anchors, with the risk of
>> trusting them for other things, the trust is anchored in DNSSEC/DANE to
>> apply only to those DNS names
>> that self identity as such.
>>
>
>> This for instance would exclude the "a user's fitness tracker" example
>> you list, because it would use the WebPKI
>> to connect to a user and then typically use some
>> authorization/authentication the the application layer for the
>> service.
>>
>
> I'm not sure how I'm supposed to get that from the text of either this
> document or the charter. Obviously one *could* build things that
> way, but you could build lots of things that way!
>
>
> Regardless, the argument cannot be "use the webpki because it offers
>> better privacy features" because for
>> players in this space, non-webpki authentication and authorization is
>> more important than a privacy feature
>> that defends only against passive attacks.
>>
>
> I think you are perhaps misunderstanding my comment, because I'm
> not talking about the WebPKI at all in this discussion. I'm instead saying
> that the client should send the DNSSEC chain in a TLS extension
> rather than having the server query for it, thus avoiding revealing
> its identity on the wire. This is entirely isomorphic to the current
> identity structure.
>

I think a TLS Server supporting DANCE has a higher change of being able to
implement DoH than an IoT client,
that would need to make updated DNS queries to build the DNSSEC data for a
TLS extension.

For one, the server is on a stable deployment with presumbly robust DNS.
While the IoT client is roaming on
some LTE network, not sure what DNS queries can be made, received of
intercepted in the clear or with forced
ADD servers, or getting ADD denied via  *use-application-dns.net
<http://use-application-dns.net>*. (eg Rogers in Canada does this right now)
Building support to pull DNSSEC records to build a list of DNS records
proving the client identity, and doing so
with private DNS itself, seems a very complicated deployment not well
suited for IoT devices.

I'm not sure why you don't think that this is a real security and privacy
> problem. If I had a fleet of trucks that were driving around, I wouldn't
> necessarily want someone who was able to observe traffic to
> see which one was reporting back from which IP address, which often
> leaks information about where someone is, even with mobile devices.
>

Having such client build DNS payloads by querying the network resolver
isn't much
better and vastly more complicated than doing it on the server end. This
becomes
even more true if the zone involved is not a public zone but a private zone
(*.fleet.internal.corp.com)
that only devices, vendors or corporate has access too. Other deployment
use cases involved
the client just knowing its own ID and cert via provisioning, and not even
knowing how where or why
their ID is in DNS.

I still think all this discussion can be summarized as "If doing DNS
queries for the TLS client names on the TLS server
side, or leaking TLS client ID on the TLS connection in the clear is not
acceptable, the DANCE protocol should not be used".

Paul