Re: [Standards] Proposal: Public Key pinning

2013-11-12 Thread Simon Tennant
On 12 November 2013 00:33, Thijs Alkemade th...@xnyhps.nl wrote:

 * DANE. DNSSEC deployment is still low and DANE is low compared to that.
 Few
 DNS stacks include support for DNSSEC, so widespread DANE deployment is
 unlikely to happen soon.


I would love to have a guide on how to setup DANE and DNSSEC for an XMPP
server. And have a primer added to the
http://wiki.xmpp.org/web/Securing_XMPP#Prosody_.28secure_delegation_with_DANE.29page.

Has anyone managed to do this?

Would anyone have time to walk me through setting this up and I'll write up
a recipe.

S.
-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP


[Standards] Proposal: Public Key pinning

2013-11-11 Thread Thijs Alkemade
Hello!

Reading [1], I thought it would be neat to have the same on XMPP.

The idea is that a server can pin the list of public keys that should be
trusted for future connections. These contain the CA's public key, the leaf
certificate's key or backup keys in case the current key is lost. This should
make it easier to secure servers that use self-signed certificates (especially
for s2s connections) and it can strengthen the security of servers that do use
CA issued certificates.

Of course, there are alternatives:

* DANE. DNSSEC deployment is still low and DANE is low compared to that. Few
DNS stacks include support for DNSSEC, so widespread DANE deployment is
unlikely to happen soon.

* SCRAM-SHA-1-PLUS can protect against MITM attacks by adversaries that don't
have the user's password, but this is not a solution that would work well for
s2s.

* TACK [2] generalizes key pinning to a TLS extension. But that means it's
probably also years away from actual deployment.

* XEP-0257. I don't think this XEP matches exactly, but it comes close and
could of course be adapted instead of introducing a new one.

Anyway, I thought a new extension would be better, so I wrote a proposal for
an extension which can be seen at [3]. It is meant to be an interim solution
until DANE gets wide adoption. The format of the pins follows [1] - but it can
also be seen as 2 1 1 or 3 1 1 TLSA records from DANE. In other words, much of
the code written to support this can be reused for DANE.

Any feedback on this proposal is very welcome. :)

Regards,
Thijs

[1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08
[2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02
[3] = https://xnyhps.nl/~thijs/linked/prosody/xep-cert-pinning.html


signature.asc
Description: Message signed with OpenPGP using GPGMail