[Members] XMPP and DNSSEC

Dave Cridland dave at cridland.net
Fri Jan 17 12:39:36 UTC 2014


On Fri, Jan 17, 2014 at 8:47 AM, Simon Tennant <simon at buddycloud.com> wrote:

> DNSSEC has the potential to help solve a lot of problems for the XMPP
> network.
>
>
Let's get a few terms straight.

DNSSEC provides signed (ie, provable) records, and signed (ie, provable)
non-existence of records. In other words, if your domain is DNSSEC-signed,
and my DNS lookup is DNSSEC capable, then I can say with certainly that the
records I looked up were as you intended me to see them, even if they don't
exist - that is, I can trust the fact they really don't exist.

DANE is a technology built on DNSSEC which allows servers to get - via
DNSSEC signed records - information about the certificate presented by a
particular service. This allows you to restrict what CA is to be used, use
a private CA, or even pin down a particular public key - amongst the many
options. DANE itself only operates on hostnames. DANE-for-SRV builds on
this to provide DANE for SRV (and MX) based protocols, including XMPP.


> Unfortunately it's not very well supported by servers.
>
> Problem:
>
>    - s2s connections blindly trust DNS for a peer's authenticity (via
>    dialback)
>
> I think the above is very confusing if you don't know the truth of it.

If a server does "classic" XEP-0220, then the net result is that a server
trusts DNS. If the server is doing TLS certificate validation, then as far
as I'm aware, all such implementations test the correct reference name in
the right places (or a selection of correct places, anyway), and therefore
explicitly do not trust DNS.

One interesting issue is that because of the number of servers which do not
have TLS, or do not have a valid cert, most servers will silently fallback
to trusting DNS in the absence of specific handling to the contrary. More
on that below.

>
>    -
>    - multi-tenant XMPP hosting + security isn't possible
>
> That's incorrect; it's generally made more difficult by services having to
have valid certificates for the domain hosted, which is quite difficult for
large third-party hosting providers. It is absolutely NOT impossible,
though, and large scale HTTP providers do just this.

What DNA and their ilk to is provide a secure association from one name -
the domain - to another - the hosting provider - and therefore allow
clients (in the network sense - so both XMPP Clients and XMPP Servers) to
use the hosting provider's name as a reference name in the TLS lookup.
Using DNSSEC here is one instance (and a useful one at that); POSH is
another which uses HTTPS instead of DNSSEC to prove the association.

> Missing Pieces in the DNSSEC puzzle:
>
>    - highlight the problem for operators: xmpp.net test for sites that
>    accept invalid certificates (
>    https://bitbucket.org/xnyhps/xmppoke/issue/12/test-for-rejecting-invalid-certificates
>    )
>
> Well, no. This is an orthogonal issue. Obviously we want servers to be
able to rely on the existence of, and test for, valid certificates, and an
interesting property of DANE-for-SRV is you can prove that a server has
such a certificate, preventing a downgrade - testing for that is very
interesting indeed.

>
>    -
>    - good documentation to solve the problem: I asked Shumon to help and
>    he's written up a great guide for how to add DNSSEC to your domain
>    http://wiki.xmpp.org/web/Securing_DNS Thanks @shumon!
>    - Server's that check against DNSSEC / implement DANE.
>
> Another missing piece is that DANE-for-SRV isn't yet an RFC. Many of the
authors of it are XMPP-friendly (including some guy called Peter
Saint-Andre), but I'm sure that they'd welcome some more reviews of the
spec so it can be pushed along the road to PS.

> Current server landscape (happy to be corrected):
>
>    - Prosody has support for  "DANE Lite" Zash describes it as "This
>    isn't using TLSA, just SRV records with DNSSEC.  I'd like to call it
>    DANE Light or somesuch."
>
> I'd call it DNSSEC. :-)

>
>    -
>    - Tigase looks like they are thinking about DNSSEC:
>    https://projects.tigase.org/issues/1626
>    - Ejabberd: can anyone comment?
>    - Openfire: can anyone comment?
>    - Other implementations?
>
> Question:
>
>    - How do we help developers to build DNSSEC support into XMPP servers?
>
> If they're using libunbound, it's really quite easy to do DNSSEC.
DANE-for-SRV is a little harder; it involves switching X.509 TAs on the fly
and things, but it's not impossible certainly. I've yet to look at the TLSA
support in libunbound, though.

>
>    -
>    - How do we help operators deploy with DNSSEC?
>
> Well, assuming by "we", you mean the XSF, I think we should first poll the
members to see if they want the XSF to be involved here.

I certainly think that the XSF working directly to support operators (and
indeed promote XMPP to potential operators and end-users) is a very
sensible thing, but I'm aware that I was vigorously argued against on this
issue in Portland - the contrary position, which to my recollection was a
majority of those in the room, was that the XSF should only be supporting
developers and nothing more.

As such, despite my firm and unchanging support for things like this, I
don't feel I can suggest the XSF do anything at all in this area without a
clear mandate from the members - and by clear, I mean unless consensus is
obvious I'd like a membership-wide vote.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/members/attachments/20140117/db65cdad/attachment.html>


More information about the Members mailing list