On Thu, Mar 21, 2013 at 11:57 PM, Phil Pennock < xmpp-operators+p...@spodhuis.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > On 2013-03-21 at 07:45 -0700, Peter Saint-Andre wrote: > > https://datatracker.ietf.org/doc/draft-miller-xmpp-posh-prooftype/ > > """ however, these technologies > are not yet widely deployed and might not be deployed in the near > future for domains outside the most common top-level domains (e.g., > ".COM", ".NET", ".EDU"). > """ > > Of 272 TLDs, 85 have DS records. [1] ARPA is not germane, so that's > 84/271. So while DNSSEC is not universal, it's certainly misleading to > imply that it's rare outside of the traditional gTLDs. Eyeballing the > list of TLDs with DNSSEC delegated through them [2] it looks to cover > most nations with a strong Internet presence; notable by their absence > are just IT, HU, CN and AU. And, perhaps ironically, PRO. ;) > > That's interesting; I wonder how prevalent ISPs within those communities are which can handle DNSSEC. > Reading that draft, it's unclear to me where "im.example.com" comes > from; is that the JID domain, thus p...@im.example.com, and so there has > to be an HTTP server at the zone apex which can be configured with XMPP > policy content, or is that derived from p...@example.com, in which case > how is the im label determined? What's the trust path to it? > > It says the source domain, which will be the JID domain as you put it. Though I'd argue that with POSH, it's less of a trust path, and more of a trust "if you nip through the broken fence then there's a hole in the hedge and you can cut across the field". It's a hack, but it's a hack that seems to be secure to my eyes, and is deployable now. > I see the value in having an alternative to DNSSEC, and even having it > around for the longer term, to be proof against mandated alternate root > anchors and inline resigning, for those stuck in countries where that > can be mandated. I'm trying to figure out what is being gained here: > something equivalent to DNS NAPTR but with PKIX validation of the > results? > > After all, if I can have appropriate certs on a web-server, served up by > domain, I can have the same on an XMPP server. The key seems to be to > rely upon SNI support in web-servers without having to make sure XMPP > servers can also do dynamic certificate selection, and also letting XMPP > hosting be delegated (thus the NAPTR aspect of things) -- am I correct > in my summarisation, or have I missed something? > With POSH, you can host your domain on Google, and have them use their Google cert. You then take that cert - with no access to the private key - and host it on your webserver, secured by your cert (and private key). So this is a case where the hostee and hoster don't have to have any shared private key, and is also a case where even though you "can have appropriate certs on a web-server, served up by domain, " yet you cannot "have the same on an XMPP server". Does that shed any further light? Dave.
