On 05/18/2011 08:03 PM, Glenn Maynard wrote: > On Wed, May 18, 2011 at 9:33 AM, Winfried Tilanus <[email protected] > <mailto:[email protected]>> wrote: > > An XHR client will also be bound to the same origin principle. So the > domain checking (and the leap of faith in that server) already happened > there. > > > No it's not; that's what CORS is for.
Using CORS doesn't really change my argument: The browser can't request the TXT records from the DNS. With or without CORS the XHR will be directed to the url provided to it. It can either be provided by the script running in the browser or by the user. So the problem you describe does not occur when using browser based BOSH clients. > But for other clients your point is valid. Because of the rapid > adaptation of DNSSEC, I believe it would be best to let DNSSEC fix the > problem, and not try to bring an intermediate fix in place in XEP-0156. > That would be the right place to fix the issue anyway, because it > started with not trusting DNS in the first place. > > It's a mistake to have security depending on DNS, when XMPP itself is > carefully designed not to do so. It's a complex and unnecessary > security dependency, making BOSH implementations and deployments much > more complicated than XMPP. > > 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. Probably I am missing the point here, but I don't see how any BOSH client has any means to check who it authenticates to: When using BOSH you connect with HTTPS (hopefully not HTTP) to the proxying web server or directly to the connection manager. The connection manager sets up its own, hopefully encrypted, connection to, again hopefully, the right XMPP server. So when using BOSH, you put a hell lot of trust in the connection manager: everything after the first hop is out of your control. BOSH equals a leap of faith in the connection manager and no BOSH client can know whether the connection manager relays to the right server. In the case of a fat client identifying the BOSH uri by looking up the DNS TXT records, there is only one TLS certificate going to be checked by the client: that of the url the TXT record pointed to. If that TXT record is compromised and points to https://evil.com/bind, and evil.com can present a valid TLS certificate, then there is no way the client can detect the evilness of evil.com. The only way out is making sure we can trust that TXT record by using DNSSEC. best wishes, Winfried
