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]
