On 07/12/2006 06:02 AM, Benjamin Podszun wrote: > Jefferson Ogata wrote: >> I do have a concern about the RFC, in the details of cn matching >> performed when SRV records are involved. While clearly you do the right >> thing in ignoring the hostname returned in an SRV record for purposes of >> cn matching, the defined approach imposes a problematic constraint on >> servers: if I want to offer a certificate for users @example.com, I must >> use a certificate for "example.com". Because the cn of this certificate >> is the domain root, if stolen it could be used to spoof other services >> for the domain root itself. Meanwhile, since jabber servers are a new >> breed, there remains a great deal of unaudited server code. The prospect >> of having a certificate for my domain root running in an unaudited piece >> of server software exposed to the world is one I do not relish. > > I have two issues with this paragraph: The first/obvious one is probably > nitpicking anyway, but I'd really like to hear what you call "new > breed". http://www.xmpp.org/history.html claims, that jabberd was 1.0 in > 2000, which is not that new to me. But as I said, this might be nitpicking.
I'm aware that XMPP has history; I still, however, consider a 2000 1.0 release new. And my strong impression is that there has been very little investigation of security vulnerabilities in XMPP implementations, which is the principle concern. Newness is not the whole story--just look at Sendmail for an example of a program that is about as old as anything in current use, yet another significant vulnerability was disclosed within recent months. Contrast, for example, the audit history of any of the popular jabber servers with that of, say, Apache. Not only are there typically many, many more eyes on Apache, Apache has also been the subject of a great deal of rigorous auditing. So I agree that "new" is a subjective characterization, but I hope you see my point. > A completely different question comes to my mind when you talk about the > certificate: Even if your certificate for the CN example.com would be > stolen, what exactly is your connection to other services here? Each > service could imo use a different certificate - if you want that. And > all your clients should notice a change of a certificate anyway? If the private key for a valid certificate for example.com is stolen, an attacker can use it to spoof any service for example.com. It doesn't matter if you use different certificates for other services. The only thing encoded in the certificate cn is the domain name. (There are usage constraints on certificates that may differentiate SSL server certificates from personal client certificates, for example, but nothing that specifies valid services.) In fact, if you do buy different certificates for different services, you're just throwing money away--a certificate for example.com is valid for any service found at that address. -- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]> "Never try to retrieve anything from a bear."--National Park Service
