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. 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). > As above, this has nothing to do with the WebPKI. I'm stipulating for the purposes of this discussion that you are authenticating with DANE. > 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. > 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. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
