23 apr 2013 kl. 21:45 skrev Richard Barnes <[email protected]>: > Dropping in late here ... > > Olle, I think you're misunderstanding the role of DANE here. Regardless of > the SRV strategy, there's no need to update RFC 5922. DANE just binds a cert > to a name; it doesn't say what needs to go in that cert. So just like RFC > 6125 didn't need to change for general TLS services, RFC 5922 doesn't need to > change for SIP. DANE might make some of the things in RFC 5922 redundant > (since you've got two ways to say what domain you're bound to), but that's > not something that urgently needs to be changed. Richard, Please check http://tools.ietf.org/html/draft-ietf-dane-srv-02 Section 7.3
"So this specification says that clients check that the server's certificate matches the server host name, to ensure that the certificate was issued by the CA to the server that the client is connecting to. " Also check Appendix B which is very clear on the same topic. This is quite different from RFC 5922, which also updates RFC 3261 and contains quite a few MUSTs. I might have missed something here, but to me it sounds like a big change unless we come up with our own way of doing DANE, which would be different from the proposals for SMTP and XMPP (if I have understood all documents right). RFC 5922 will still apply for non-DANE clients - but my biggest worry is the certificates. RFC 5922 hasn't really been used, I've seen no commercial vendors that sign certs with SIP URI's in subj alt names. If a server needs to support both (and doesn't support TLS SNI) the certificate requirements will lead to a messy cert indeed. We will have to have server names for all the servers in the SRV DNS alt names, all the supported SIP domains in URI subj alt names. That's quite a lot of information in one certificate for a service, and something that will be hard to get people to create and install. If we're not going down this route, which name do we use in DNS to find data related to the SIP certificate for a domain? /O > > --Richard > > > > > On Sun, Apr 21, 2013 at 6:27 AM, Olle E. Johansson <[email protected]> wrote: > Hi! > > Looking at the DANE SRV draft with my SIP eyes I realize that there's a lot > of work to be done to get this > to work with SIP. > > SIP has no StartTLS, we use NAPTR records to select transport. The NAPTR > points to a SRV > name that resolves into a set of host names. > > The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - > specificies matching a > given SIP URI with a certificate. The matching is done on service domain > either with > a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but not the > host name. > > I personally agree with the policy in the DANE SRV draft that we should match > on the > SRV hostname used to get A/AAAA records when using DNSsec. For this to work, > the path from the SIP URI over NAPTR to SRV and hostnames needs to be fully > signed in and verified in the DNS. This is going to require an update to 5922. > > The final question is how to handle this without SNI. The certificates for > both > DANE verification and RFC 5922 plus "old-style" verification with the sip > domain in the CN seems like a complicated mess to manage. > > Food for thought on a sunny Sunday. > > The SRV draft is not clear on how to use Subject AltNames of various types, > and doesn't mention NAPTR. I am not personally aware of other protocols using > this setup, so maybe this requires a very SIP specfic draft, following the > wake of the > smtp work. > > /O > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
