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

Reply via email to