On 2013-03-22 at 10:16 +0000, Dave Cridland wrote: > That's interesting; I wonder how prevalent ISPs within those communities > are which can handle DNSSEC.
I use Joker for registrations; they're a CORE member, which seems to imply that any CORE registrar can handle DNSSEC, if they so choose: they have the backing infrastructure, it's all down to them. When I was at an ISP, we were a CORE member for a variety of good reasons, both technological and financial. That was in NL. So any limitations are down to the ISP in question and their structure. > 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. Thanks, I needed that smile. > 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? Yes: it's "letting XMPP hosting be delegated (thus the NAPTR aspect of things)" -- NAPTR style delegation, but using existing trust paths for HTTPS to the redirector, instead of needing DNSSEC to secure the NAPTR. So it's what I thought. Valuable, but perhaps overstated to date and a draft specification could do with actually explicitly laying out the use-case and what it buys you. On 2013-03-22 at 09:00 -0500, Jesse Thompson wrote: > 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. How strange. I have DNSSEC/DANE actually deployed, to my server, since yesterday. I've had the DANE cert in place a little longer, this was just adding a couple of CNAMEs to DNS. So the publishing part is in place. It was only CNAMEs, because I already had the TLSA cert in DNS, for use with other protocols. The path-to-anchor verification can be done trivially, with a validating resolver. I use unbound, for various reasons, but Bind can be configured to be validating too. So what's left, for *both* options, is adding code to manage getting the trust anchor, in a secure way, to the validation for the target connection within the connection client program. -Phil
