-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sending to [email protected] just to add more to the subject line. :P

For those who aren't on the buddycloud-dev or prosody-users lists, the
original message is here:

https://groups.google.com/forum/?_escaped_fragment_=msg/prosody-users/qAKRn0fzxDk/RvEAQIiPNDEJ#!msg/prosody-users/qAKRn0fzxDk/RvEAQIiPNDEJ

On 8/21/13 12:37 PM, Philipp Hancke wrote:
> Am 21.08.2013 17:15, schrieb Kim Alvefur:
>> On 2013-08-21 16:30, Simon Tennant wrote:
>>> We're well overdue a SEX (Security and Encryption in XMPP) day
>>> where all major XMPP operators disable s2s and c2s cleartext
>>> connections. This would be similar to the ipv6 day last year.
>>> The aim being to get all major sites switched over in one go.
>> 
>> Let's do this! :)
>> 
>> Perhaps, like the IPv6 day before the IPv6 Launch Day, we run it
>> for just one day at first.
> 
> I'm ok with C2S, but I'd love to know how much breaks on s2s
> first.

You want to know how much breaks on s2s before we force-TLS on c2s?

> Basically what I did back in 2007 at 
> http://mail.jabber.org/pipermail/standards/2007-July/016086.html

I sure hope we can do better than that now!

> I suppose we actually need some POSH deployment before we can 
> realistically enforce this.

At least for interoperating with hosted services, yes.

> But telling people that their cert is broken is quite possible now.
> As long as Peter tells them that 'but it works with jabber.org' is
> not an argument ;-)

It isn't!

And now that we've upgraded the jabber.org server, the jabber.org
admin team is talking about how we can start to move in a more secure
direction (although force-TLS on s2s is not the top priority for
various reasons).

As I wrote somewhere else in this thread...

###

The XMPP Council had a discussion about this topic after its meeting
this morning:

http://logs.xmpp.org/council/130821/

There are many possible steps to take:

1. No user registration (XEP-0078) without TLS.

2. No SASL PLAIN without TLS.

3. No client-to-server connections without TLS.

4. Require stronger authentication (e.g., SCRAM-SHA1-PLUS, which ties
the SASL exchange to the TLS negotiation).

5. No server-to-server connections without TLS.

6. Require proper certificate checking (RFC 6120 / RFC 6125) for TLS
negotiations.

7. Require support for CRLs/OCSP to detect expired/revoked certs.

And there are probably more.

In the Council meeting, Kevin Smith raised a good point: we need to
have a plan for when to do those various things. Doing them all at
once will lead to operational issues because it will be hard to debug
why certain users can't connect (etc.). However, I think we all agree
that those goals are desirable and that we want to move in that direction.

###

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSFQyAAAoJEOoGpJErxa2pidYP/2MZ9MPCR6ngqSih/LC4m2JF
Lw9JgkxPLcS3oBAdzesW/2014kjk5ueIJSngHlWYHGcChr994yTNk5sW0TT2NmfK
Rtkykw/ZbBBwhYtxO6wfCNruVK4Obfyyx/YbkC/uevkvJMeSZpCZG2AurSdbhKzq
Ci2McsWXwCV6x2TrGfX5/jJgQ57dg9TSK85uY3npyk1HdF11akzvfzqLpomY8bi1
7mG0W1qjOlCBtv7Nm3YFkYeTAANA5wdH4qsc996TQwhTeAJXnzfvRjU/yxWQBlbZ
ioqthpAGwy6Ew85t3bA15UTC6p2xDRPO7gRYv5TUBk6F+so+3RMDCiKORPjWpwS+
SVGrKsoQCzyKOMAGjylB8R0o4kf3ehmU6CqvTW5I3h4y5e/jgS/yNG50mfHO+oQj
hjsl0sdeMz+3M5NJAY8zGIuuuZWbVA8gbjPCz9gdBSAcPtkjFe9GaJqYxntrcqsN
gCaZEz2E0DgVmTkFU/ak0llfbnpY8d0gMdOPmVRjybi6zmtCca9uALxqudnRqPaV
BCbTpjzlnJajkoiYsJYjRAVxrTC75KrtJGI0qYhb/P8+Xa0A0ewBUUd65IoysgNh
8U9UeKGXgv56VS55B9Pydsd+7YomrDvzxdCW3otlUW5UeqPwD8TeHcdA5xW/Ti0Z
HLnuwyClxFX0Jtdon98m
=W0GP
-----END PGP SIGNATURE-----

Reply via email to