* Thanks for the review Eric. Yes, we should have looped in the TLS * working group earlier. (I've cc'd them).
Thanks for that. * This draft's origin predated TLS 1.3, and earlier work on it happened when * TLS 1.3 wasn't as widely deployed as it is now. Yes, had TLS WG been involved earlier, it would have been better known I guess :) * I would be inclined to just remove TLS 1.2 support from the specification, if * there is agreement. You will have to do that, since the extension can ONLY be registered for TLS 1.3 * > 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. > 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. As a bare minimum, if no changes are made, the security considerations should make this exposure explicit. >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.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
