[Standards] Dialback, authentication, and authorization

Dave Cridland dave at cridland.net
Wed Nov 13 13:38:08 UTC 2013

On Wed, Nov 13, 2013 at 1:27 PM, Thijs Alkemade <thijs at xnyhps.nl> wrote:

> On 13 nov. 2013, at 12:56, Dave Cridland <dave at cridland.net> wrote:
> > Then there's the "same-cert" shortcut, where the receiver connects to
> the authoritative server and compares certs. This is an interesting case,
> because we're deriving identity (and therefore authenticating) from the
> certificate, but the certificate isn't sufficient to authorize - so we
> dialback to the authoritative server and if the certificate matches, this
> is sufficient authorization.
> >
> > What we're now debating is whether we need a trusted identity in
> same-cert, or whether a self-signed certificate is sufficient. We need to
> be assured that the identity is unique - that is, that the private key is
> known only to the authorized party, basically, and I'm personally concerned
> that there could be cases of TLS and/or XMPP implementations shipping with
> a sample certificate then used in production.
> >
> > What do people think?
> >
> > Dave.
> I’ve added a table to the xmpp.net stats page showing which domains share
> a
> public key:
> https://xmpp.net/reports.php#sharesprivatekeys
> It checks the SPKI field, so the certificates may be different but the
> public
> key on them is the same.
Right. There are some interesting cases where you might deliberately and
legitimately have multiple certificates with the same private key, in
particular where hardware crypto is involved.

> Of course many are harmless false positives, there might be good reasons
> why
> two domains share a key. But those of note are:
> Prosody's default key:
> F7:D9:2E:68:43:43:A9:EA:2E:BE:5F:FA:4B:B7:B9:25:EC:3C:03:5B:85:B5:C4:38:48:0E:8A:9A:71:66:E6:E6
> Ejabberd's default key:
> C5:78:17:B1:34:90:54:D0:5A:16:A4:C6:71:80:6D:C3:F8:8B:F1:31:3D:64:BD:42:8F:1F:C5:D9:21:EB:99:BE
Ouch. I think we should recommend strongly somewhere that XMPP
implementations do not ship with a default key.

To state the obvious, this means that any TLS channel not using PFS on
these default keys is decryptable; the private key is, in effect,

> Thijs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131113/c32cb20e/attachment.html>

More information about the Standards mailing list