Subject: [xmpp] Fwd: [dane] DANE XMPP s2s implementation

From: Kim Alvefur <[email-masked]>
Date: Mon, 10 Mar 2014 15:51:24 +0100

Also relevant here.

-------- Original Message --------
Subject: [dane] DANE XMPP s2s implementation
Date: Mon, 10 Mar 2014 15:50:17 +0100
From: Kim Alvefur <[email-masked]>
To: DANE WG <[email-masked]>

Hi,

Everyone back (and recovered) from IETF89?  Much interesting, such
people, very discussions, wow.

So I have an experimental DANE implementation for server-to-server
connections in the Prosody XMPP server.

It's currently only doing DANE-EE and PKIX-EE.  The TA variants are
trickier, especially DANE-TA, so I have left them out for now.  LuaSec,
the OpenSSL to Lua binding we use, doesn't currently expose anything for
validating some random chain.

It also includes an attempt at doing something for authenticating the
client certificate on incoming connections, by looking for a TLSA record
at the same name as for SRV, eg _xmpp-server._tcp.example.com.  Comments
about this would be appreciated.

Info: http://code.google.com/p/prosody-modules/wiki/mod_s2s_auth_dane
Code:
http://code.google.com/p/prosody-modules/source/browse/mod_s2s_auth_dane/mod_s2s_auth_dane.lua

--
Regards,
Kim "Zash" Alvefur

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Mar 2014 12:15:07 -0600

FYI from the DANE list. Discussion here seems appropriate.

-------- Original Message --------
Subject: Re: [dane] DANE XMPP s2s implementation
Date: Mon, 10 Mar 2014 16:13:50 +0000
From: Viktor Dukhovni <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

On Mon, Mar 10, 2014 at 03:50:17PM +0100, Kim Alvefur wrote:

> It's currently only doing DANE-EE and PKIX-EE.

I would recommend that, as with the SMTP draft, the XMPP community
choose a subset of the DANE usages to support.  Either 0/1 or 2/3,
but not both.  By choosing both you get the weakest security, and
the maximal deployment friction (everyone needs to deploy and trust
the same set of CAs).

So it makes more sense to implement just one of DANE-EE or PKIX-EE,
with a plan to later add one of DANE-TA or PKIX-TA respectively.

> The TA variants are
> trickier, especially DANE-TA, so I have left them out for now.

Indeed, especially for DANE-TA, it makes sense to wait until the
underlying TLS toolkits: OpenSSL, NSS, GnuTLS, ... support DANE
trust chain verification and name checks (integrated with trust
validation because DANE-EE obviates name checks, while DANE-TA
requires them).

Though IIRC the XMPP draft currently just defers all the DANE
language to the SRV draft, it may at some point make sense to be
more explicit about XMPP-specific choices, unless the SRV draft is
modified to define a set of profiles, one of which exactly matches
the requirements of XMPP.

> about this would be appreciated.

I encourage you to discuss this with the XMPP draft authors,  I
asked this very question informally and was told that client
certificate verification was somehow accomplished via callbacks.

If it is reasonable to require the outbound XMPP clients for a
domain to possess the same private keys and certificates as the
inbound servers, then your approach may reasonable.  Though you
likely end up taking the union of the TLSA records for all servers,
rather than just the specific server you connect to when validating
a connection to a server.

I would suggest a less ad-hoc strategy for authenticating clients,
perhaps a lookup key for TLSA records at:

	_xmpp-client.example.com IN TLSA ...

if client certificates are to be used with XMPP to authenticate
the client domain.  (Neither _port nor _proto make much sense for
clients, the client is not a fixed transport end-point).

-- 
	Viktor.

_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane