On Mon, Jan 26, 2026 at 1:37 PM Eric Rescorla <[email protected]> wrote:
> > > On Mon, Jan 26, 2026 at 10:23 AM Paul Wouters <[email protected]> > wrote: > >> >> On Mon, Jan 26, 2026 at 12:59 PM Eric Rescorla <[email protected]> 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
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
