On Mon, Jan 26, 2026 at 10:56 AM Salz, Rich <[email protected]> wrote:
> > > - > This has the effect of revealing the client's identity on the wire. > > > > - It does, I guess unless encrypted DNS transport is being used. > - A number of other protocol mechanisms already have similar problems, > - don't they, like TLS client's lookup of SVCB records for ECH, etc, if > - not done with encrypted DNS transport. > > > 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. > 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. Especially in cases where hiding the client identity for the application may not be that important (like a warehouse full of machine identities). Careful use of encrypted DNS resolvers can also mitigate this and could be a recommendation. > 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]
