Last night (or very early this morning), the
spodhuis.org (this grumpy troll's primary domain)
received an upgrade.
TLS trust verification for
outbound connections can now be performed via DANE lookups.
is a mechanism, using DNS, DNSSEC and a
TLSA record type, to provide
verifiable information in DNS about the trust anchors for reaching a
particular service, such that verifying the certificate or public key
identifying the remote end of a TLS connection need only rely upon the data in
There are interesting issues to explore, covered here previously, around the trust relationships and attack modes against DNSSEC, but by now it's abundantly clear that the Certificate Authority model is mostly broken, even for the scenarios where its proponents claim that it's well-suited.
For a federated service, where servers talk to servers and the human originating a message is not in a feedback path for accepting TLS identity problems, anything based on “trust this set of people” will either become a very select few organisations who might be mostly trusted, or an ever-growing set of organisations who must be trusted, lest the local powers-that-be come to complain about messages getting through, degenerating into “trusting everyone”, or “being a sucker”.
Thus for services such as SMTP between servers (the so-called “MX Delivery”) or for XMPP between servers, letting the people who control the DNS control which certificates are valid has a number of benefits, provided that you can be confident that verifiers will have access to trustworthy signing roots, and that's “someone else's problem”. Nor is it even an abusive externality, because the people having to solve their local trust anchor issues need to do so, for themselves, in any case.
The interesting part which is a subject of current exploration is in the use of TLSA records for also identifying valid origin identities for a connection, not just the receiver identities.
The biggest problem is that the TLS security libraries commonly available are not very amenable to the tinkering with their verification flows to let DANE be added easily.
Back to spodhuis: for XMPP, I use Prosody as server software. It's written in Lua, a scripting language and thus probably mostly immune to many classes of attack, and it is actively maintained by someone well versed in XMPP and involved in the standards work. It is quickly becoming a de-facto open default implementation and my experiences have been mostly positive. I endorse this product.
A while back, I pimped the possibilities of DANE on the XMPP Operators forum, without actually doing any heavy lifting of coding for myself. I did publish the trust anchors for my existing certificates in DNS; this was almost trivially simple. I already had DNSSEC signing for my domains, I already have validating recursive resolvers (via Unbound) and publishing metadata about a certificate does not require any service changes. As a server operator, you publish extra data in DNS letting clients validate your existing certificates, that's it. No code changes.
I got lucky, this was sufficient for Zash, the maintainer, to not only take a look but to implement support.
At this point it should be emphasized that Prosody support for DANE is highly experimental and might be insecure. Zash doesn't want people to rely solely upon this just yet, more peer review and analysis is needed.
Against that, rather than require a large set of CAs, including some known to be … ‘problematic’, I run the spodhuis.org XMPP service to accept unauthenticated TLS. So for me, the worst case scenario for the DANE support is “a problem in the LuaJIT or the C code exposing a buffer overflow” but the most likely bad case is “degenerates to provide no more security than I had before”.
In a setup like that, it's a no-brainer to enable DANE support and get some experience with it and help move towards a world where XMPP can be sanely and reasonably set to default to requiring authenticated TLS.
Thus yesterday I got a roster request from Zash, after which he confirmed that he was verifying his server's connection to mine via DANE, and I decided that I would deploy that evening, after work. There were a few teething issues, but far fewer than I would expect for being the first person other than the author to deploy an author's new code. And believe you me, I have plenty of experience of that – it's why I normally prefer to be very conservative in my choices of infrastructure components.
Now I just need to use Zash's work and Viktor Dukhovni's work on Postfix as guidelines and finally get around to adding full DANE support to Exim, but I suspect that Todd Lyons will beat me to it.
-The Grumpy Troll