Hi Paul, 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--and it's not even described as exhaustive--and I don't agree at all that client identities aren't relevant for some of these settings, for instance authentication to DNS servers by user devices. The DANCE architecture document is far more expansive, as discussed in my review [0]. This document itself doesn't say anything about restricted scope. [1] Second, even if we do think that there is a more restricted scope, it's the WG's burden to do some real analysis to demonstrate that that scope has more limited need for privacy properties. For example, just because devices have names that are meaningless doesn't mean that revealing those names isn't a privacy issue. For example, consider the case of some sort of personal device such as a fitness tracker, which connects back to the vendor to upload data. Even if it identifies itself solely by serial number, knowing that serial number allows an observer to link up multiple transmissions by the same user, which has obvious privacy implications. Finally, while I agree that in some limited applicability cases, we make different security and privacy tradeoffs, we typically only do so once we've satisfied ourselves that it's not practical to design a system which has more generally appropriate properties. In this case, we have an at least potentially viable alternative design, with the main objection being raised that it involves more burden on the client. It's possible that that's actually prohibitive, but it seems like at minimum we should be attempting to determine whether that's so, rather than just assuming that it is. -Ekr [0] https://mailarchive.ietf.org/arch/msg/dance/RLSNjxjwhGCPxdTw-gtLMcOFg0c/ [1] I think this also addresses your point about how this should have been raised at chartering time, because, as noted above, neither the charter nor the drafts plainly indicates such a narrow scope, and so this objection wouldn't have been timely. On Mon, Jan 26, 2026 at 9:28 AM Paul Wouters <[email protected]> wrote: > > On Mon, Jan 26, 2026 at 11:51 AM Eric Rescorla <[email protected]> wrote: > >> >> 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. >> > > The use cases involved do not have endusers with privacy concerns. It is > already known that a zonewalk can get you > all the x509 information and a query log to a target gets you a mapping of > tls server/clients doing such dance based > authorization/authentication. The fact that TLS itself got a privacy bump > does not really negate this use case or add > further compromise of privacy of the devices. > > That is, these deployments care about content encryption and > authentication but don't really care about mapping out > client identities to IP address (via either IP monitoring, DNS query > monitoring, or TLS handshake leakages) > > >>> > 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? >> > > The target audience was always those who don't care about leaking SNI or > client identifiers. > These would also typically not be endusers, but a container full of IoT > devices where for > example a CN= is pretty meaningless other than as a unique identifier > mapped elsewhere > (eg within the inventory system of the fleet manager for these devices( > > >> >> 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. >> > > This would have been a great argument for a BoF or Charter, but we have > many years past that discusion. > The fact that TLS 1.3 is a bit more secure than TLS 1.2 should not mean > this use case is now somehow > "not allowed anymore". > > >> I would observe that the DANCE architecture document makes quite >> expansive applicability claims which would clearly be in tension with this >> kind of limitation. >> > > That can be addressed in that document. > > >> 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. >> > > It is common for IoT devices (eg google chromecast) to actually leave the > factory with preconfigured DoH > servers to use. It is not that far fetched to imagine other IoT devices > would do the same, especially since > these are deployments of IoT devices that are truly fleet managed with > central provisioning, and not general > purpose enduser devices. > > > Paul > > >> > 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. >> >>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
