[Operators] XMPP Security Talk to IAB
xmpp-operators at sotecware.net
Sun Aug 31 20:35:07 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 29.08.2014 10:54, Dave Cridland wrote:
> I've been asked to give a talk next Wednesday to the Internet
> Architecture Board - the senior panel of the IETF - about the
> changes we made to encryption on the XMPP network.
> I'm interested in highlighting why operators chose to enable
> encryption, make it mandatory, and other security choices. Stories
> of the challenges you guys faced, and what compromises you felt
> forced to make, and so on are also going to be very interesting to
> the audience. Human factors in your choices are just as interesting
> as technical ones - a lot of what we do is around people
> communicating, so impact to that fundamental ability is of course
> important. Facts and figures are welcome if you have them,
> anecdotes are good either way.
Okay, I assume some stories about the difficulties will follow. I’ll
raise the voice for those who have not had any (or rather few)
I maintain a federating server for a group of friends (actually,
anyone who asks me politely for an XMPP account, around 15 users
probably). We’re running prosody there, which makes things quite
trivial, in my opinion (at least, if you’re not running a redhat-ish
linux. I am running a redhat-ish linux).
A story about the technical part
The domain is future-proofed -- being in the well deployed .net TLD,
we have access to DNSSEC and have DANE deployed (and it seems to work
well according to the xmpp.net tests). The DNSSEC deployment is
via our own nameservers, I don’t know whether the registrar supports
DNSSEC via solely their nameservers as we had that infrastructure in
place before we had DNSSEC set up.
As for the choice of cipher suites et cetera, I totally rely on the
prosody developers. I have deployed larger diffie-hellman groups
manually, which led to some issues with outdated windows clients
(easily fixed by updating), but works surprisingly well even with my
horribly outdated android. 
A story about the human part
I care a lot about the security of my users, as many of them are close
friends or relatives. So my choice would always be in favor of the
security, and people would have to explicitly turn it off (e.g. by
choosing a different server).
When the manifesto was announced last winter, I joined the test days.
There were no apparent interruptions -- I advised my users to inform
me about any problems which arised, and noone came back to me. I left
the c2s-encryption-required switch in place (there would have been
out-of-band measures to reach me if that had been a problem), but
flipped s2s back. The next test day was missed, at some point (I think
during another test day or the final switch-day), I left the s2s
encryption requirement enabled, and it is there since then.
Apart from small glitches, everything went smooth.
Good luck with your talk :)
: In case anyone wonders why the server doesn’t support ECC,
see <https://bugzilla.redhat.com/show_bug.cgi?id=319901>. Can’t
wait for the djb curves to hit TLS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the Operators