On Thu, May 19, 2011 at 6:16 AM, Dave Cridland <[email protected]> wrote:
> On Wed May 18 19:03:58 2011, Glenn Maynard wrote: > >> There also seems to be a fundamental issue with depending on DNSSEC when >> also depending on TLS certificates: there are two separate trust chains. >> With TLS, root CAs have to be trusted; with DNSSEC, DNS registrars have to >> be trusted. By not trusting DNS, an entire chain of trust is avoided. >> > > That's not entirely accurate. > > DNSSEC relies on trusting IANA; there is one single Trust Anchor for the > entire DNS (DLV aside, anyway). But the trust only extends to trusting the > records; you might be assured that the record you receive really is from > example.org, for example, but there's no telling who example.org *is*. > The problem is that with this discovery mechanism, BOSH depends on both trusting DNSSEC and trusting TLS in order to establish a trusted connection. If either trust is compromised, security is lost. If DNSSEC is compromised, an attacker can redirect the TXT record to point to https://evil.com; if the site's TLS certificate is compromised, he can MITM the BOSH server. In practice I'm concerned about requiring DNSSEC at all--I'm not convinced that using DNSSEC will ever be the default, rather than an additional, complex dependency to get in the way of secure BOSH installations. I don't think security should be designed that depends on DNSSEC until it's actually widely deployed and shown to be practical for everyone to use. I suspect that if the discovery points to evil.org, we'd use evil.org as the > authorization identifier to locate in the certificate. This is indeed > unfortunate, and relies on a secure (ie, DNSSEC) SRV/TXT pointer to > evil.org. > > But in practise I'm not sure what more we can hope for - the domain name > validated by a browser-based BOSH client will be selected by the browser. > The solution there would be to add an additional record that can then be > used for validation, so we'd have: > If discovery is made via XMPP itself, then no additional trust dependencies are needed. Perform a SRV lookup to find the regular XMPP server for the domain, connect to it using XMPP's TLS rules (which don't have this problem), and ask it where its BOSH server is. This is also far simpler to deploy than DNSSEC. For combined XMPP servers that handle both XMPP and BOSH, it would require no additional work for the administrator at all; it would just work. It's not trivial, of course, but it's one solution. _xmppconnect IN TXT "_xmpp-client-xbosh=https://bosh.jabber.org:5280/bind"; > _xmppconnect IN A 172.16.37.54 > _xmppconnect IN AAAA fe80::1 > > And browsers then ignore the hostname supplied by the _xmppconnect TXT > record and instead use (and therefore validate) the _xmppconnect address > record, which should essentially work. It *is* quite certainly a hack, > though, and I'm quite sure this isn't a finished solution. > More simply for XHR, by requiring secure _xmppconnect lookups to point at themselves, eg: _xmppconnect IN TXT "_xmpp-client-xbosh= https://_xmppconnect.jabber.org:5280/bind<https://bosh.jabber.org:5280/bind> " _xmppconnect IN A 172.16.37.54 or, more likely, a CNAME. The short explanation of this approach is something like "if the host portion of the discovered URL isn't the domainpart of the JID or _xmppconnect.domainpart, the connection should be considered insecure". That has the problem I originally mentioned, though: it would effectively prevent pointing at a third-party BOSH server. If 172.16.37.54 is actually bosh.google.com, it won't have a certificate for _xmppconnect.jabber.org. I assume that's a case BOSH is meant to support. (I also wouldn't be thrilled about paying another ten bucks a year for an _ xmppconnect.zewt.org certificate--a smaller issue, of course, but another bump in the road for secure installations.) -- Glenn Maynard
