[jdev] manifesto & DANE does not cut it

Thijs Alkemade thijs at xnyhps.nl
Tue Nov 19 12:29:15 UTC 2013


On 19 nov. 2013, at 12:58, Ralf Skyper Kaiser <skyper at thc.org> wrote:

> Hi
> 
> 
> On Tue, Nov 19, 2013 at 11:37 AM, Simon Tennant <simon at buddycloud.com> wrote:
> I don't think anyone here is advocating for downgrading security or not respecing human rights. 
> 
> I do think that we're being pretty sanguine about not letting the perfect become the enemy of the good and incrementally upgrading XMPP's security.
> 
> Good security is based on layering trust and trust points being open to inspection. DNS is about as open as you can get and comes with a pretty good "api". I'd expect that services like the SSL Observatory start offering a service that inspects DNSSEC records. And publish any oddities.
> 
> Regarding having to trust the owner of . changing keys, presumably pinning the root key would mean that you would notice it changing? DNSSEC would let you could pin any other keys in your app and notice them changing.
> 
> Nevertheless, Tony makes a good point: a cut in the namespace would be pretty obvious to all.
> 
> No it would not. This is the wrong assumption. The ROOT or the TLD KEY can be (ab)used to perform a active attack. Nobody but the targeted user would see the changed public key and then it would vanish.
> 
> This attack and vulnerability in the TLS authentication has been recognized by all major browser manufactures. Pinning (on top of DNSSEC) is being implemented as we speak. Why jabber tries so hard of being less secure than the web browser is a mystery to me.
> 
> regards,
> 
> ralf

Hello,

I think it is important to make a distinction between suggested key pinning
and automatic key pinning. Suggested key pinning is what is proposed in [1]
and [2], automatic key pinning is what SSH uses.

Automatic key pinning works for SSH, because private keys are rarely changed
and people are more tech-savy than average XMPP users. If you start doing this
for XMPP, you'll see a lot of false positives. I doubt you can convince a
large part of the network to start using self-signed certificates valid for a
long time. Every time a user who doesn't understand the security implications
removes a pin, the security of the system is weakened because it makes MitM
attacks easier. The manifesto requires software to be able to inform users
when a certificate changes and I think this is the right approach to automatic
pinning.

Suggested key pinning would be the server telling the client "please verify
one of these keys is used on your next connection: xxx, yyy". I'm greatly in
favor of this, and for those who might have missed it, I wrote a proposal on
how to apply it to XMPP on [3].

But right now this is just a proposal, with no working code to go with it.
With the manifesto going in affect on May 19 2014, I think making this a
required part of it would be too soon.

[1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
[2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02
[3] = http://mail.jabber.org/pipermail/standards/2013-November/028229.html

Regards,
Thijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20131119/660a01a3/attachment-0001.pgp>


More information about the JDev mailing list