On Friday, March 22, 2013 5:16:05 AM, Dave Cridland wrote:
On Thu, Mar 21, 2013 at 11:57 PM, Phil Pennock
<[email protected]
<mailto:[email protected]>> 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 [email protected]
<mailto:[email protected]>, 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 [email protected]
<mailto:[email protected]>, 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?
Jesse
