I'm having what seems to me a very peculiar argument over in DANE. There's a draft called draft-huque-dane-client-cert-02 about validating SSL certificates for client hosts. The idea, which seems reasonable, is that if an SMTP or other client presents a TLS certificate claiming that it's outbound.example.com, the server it's talking to can look up a TLSA record to see if the certificate is valid, analogously to the way a client looks up the server's TLSA.
What's peculiar is the names. The previous proposal was to look up a TLSA at _smtp.outbound.example.com, then somone noted that _smtp is for servers, so they want to look up the newly invented name _smtp-client.outbound.example.com. If you have a client for some other service, you make up a name. (Read the draft if this seems like an implausible summary.) I suggested they could avoid a lot of future name collision pain by registering "client" as a pseudo_service name, and then looking up _smtp._client._tcp.outbound.example.com. If your client is using another service, you use the service's name from the existing registry of services instead of _smtp, e.g., _imaps._client.tcp.myhost.example. The DANE crowd thinks this is a terrible idea, it's too complicated, makes the SRV-ID verification harder, name collisions won't happen and/or are easily solved. Am I missing something, or are they? Signed, Confused _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop