On Mar 22, 2013, at 8:00 AM, Jesse Thompson <jesse.thomp...@doit.wisc.edu> wrote:
> On Friday, March 22, 2013 5:16:05 AM, Dave Cridland wrote: >> >> >> >> On Thu, Mar 21, 2013 at 11:57 PM, Phil Pennock >> <xmpp-operators+p...@spodhuis.org >> <mailto: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 >> <http://im.example.com>" comes >> from; is that the JID domain, thus p...@im.example.com >> <mailto: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 >> <mailto: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. > > I like the concept of POSH to bridge the gap until DNSSEC is prevalent. I'd > advise keeping the focus on POSH for now, because it's something that > operators could actually deploy to production services today. > > Are there any example implementations of XMPP-POSH yet? > > Are there any other non-XMPP examples of POSH being used in the real world? > I am not aware of anyone that has yet implemented POSH, for XMPP or otherwise. I'd love to get experimental feedback on this, including as a guinea pig for an implementer. - m&m Matthew A. Miller < http://goo.gl/LK55L >
smime.p7s
Description: S/MIME cryptographic signature
