RFC 5922’s demand for a sip: URL SubjAltName for each domain which a given server supports is unfortunate.
I can understand the motivation, at least for a non-dnssec world, but it doesn't scale very well at all. My MX only needs a single DNS SubAltName (or CN) for its hostname to handle every incoming mail zone for which it is advertized as an MX. My outgoing mail server also needs such a simple cert for itself. Plus, a single wildcard cert can support both. Which simplifies things enormously. To accept incoming sip INVITEs for each valid email address would require more than a dozen URI SubjAltNames. And, as you wrote, who would sign it for the benefit of non-dane remotes? I doubt even the free signers support multiple disparate names, and I have no idea whether they’ll leave URI SANs in when signing the request. All of sip/tls/tcp, sip/d?tls/sctp, sip/dtls/udp and sip/websocket would work better were everything to support the ideas of authenticating the node and trusting naptr/srv/tlsa lookups (by way of dnssec). That said, if the 5922 semantics are to be followed and a node expects a remote’s cert to contain URI SAN sip:example.com and the naptr+srv pointed to tcp port 5061 on host flubber.example.net, then should it look for a tlsa RR at _5061._tcp_.example.com or at _5061._tcp.flubber.example.net? Perhaps it should try both? Do any sip proxies or other nodes support SNI? That would have a significant affect on what a node could provide. It would help to know what other sip implementors think of the vaious options. If SIP needs its own RFC for how to implement DANE, that is OK. The MX/SRV draft is a good basis for most services, but where there are legacy requirements which contraindicate its presumptions and/or conclusions, protocol-specific drafts are welcome. -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
