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. 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. > --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] > It can add some clarification for that. > 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. > See above. I do not think so. The core premise of the charter is "we cannot use WebPKI", so arguing that webpki must be used because otherwise some privacy property of "using TLS 1.3 in webpki" is lost seems not very relevant. But I agree it does need to be stated somewhere (either in the arch doc, or this protocol doc or both). > 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. > See above. I believe your example would not be a valid deployment case for dance. Think more of a fleet of GPS trackers reporting where trucks in a fleet are, and then Customer2232524545 appears in plain text on IP a.b.c.d reporting to bigfleet.com. > 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. > We did. The WebPKI + app layer auth was precluded from being a solution. > 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. > I also feel this is more a charter discussion item, and we are way past charter discussions. Paul > > > -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]
