<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">Im running my servers since five years now. I have a good documentation on my page which servers are not reachable. It's a point where I am very strict. No s2s encryption no service. In those five years I had two tickets from users which tried to reach a server which was not able to encrypt. </div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Von: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:mwild1@gmail.com">Matthew Wild</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Gesendet: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">‎05.‎10.‎2015 15:26</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">An: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:operators@xmpp.org">XMPP Operators Group</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Betreff: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [Operators] Please enable Forward Secrecy for your servers!</span><br><br></div>On 5 October 2015 at 02:04, Mike Barnes <mike@bremensaki.com> wrote:<br>> What we need to be doing is putting information about the quality of<br>> encryption used in a conversation in front of the users, and letting<br>> them make informed decisions, instead of fracturing the network<br>> invisibly.<br><br>I semi-agree. Once I would have completely agreed :)<br><br>One problem is that this approach leads to overloading the user with<br>information (that they aren't really qualified to make a choice on).<br>You will notice that the current trend in browsers is now removing<br>this information as much as possible, and just doing the "right"<br>thing. Websites with incorrect certificates used to show a warning<br>padlock, now they throw up big alert pages that are hard to bypass.<br><br>> Is there any defined mechanism to do this? Users are accustomed to the<br>> little padlock icons on web URLs, can XMPP client software easily<br>> implement something like this or will it need server extensions to<br>> report back? As a temporary measure, could the server send a direct<br>> message to a user alerting them if the encryption on a connection they<br>> initiate falls below a desired threshold?<br><br>It would need the server's help. This has in fact been discussed<br>before, a long time ago. I think there was even a XEP. The problem is<br>that it wasn't enough. The server doesn't always have a connection<br>open to the remote server, so it doesn't know (in advance) what<br>security proprties it has.<br><br>Then, when it does have a connection, this is easily changed. An<br>attacker with access to the network could let the secure connection<br>through, so that the client displays the padlock. Then when the client<br>sends a message, quickly break the secure connection, and ensure only<br>an insecure one can be established.<br><br>> Inform the users, don't cut them off from their contacts and leave<br>> them no path to even tell them why.<br><br>I think a better option is to let the user decide whether what they<br>are sending is sensitive or not, and the level of security to apply to<br>that particular message. That way, their (obviously trusted) server<br>will never send a sensitive message over an insecure connection, etc.<br>A failure would result in a delivery error, which can be handled by<br>the user's client.<br><br>This is technically achievable using security labels<br>(http://xmpp.org/extensions/xep-0258.html ), though it hasn't really<br>been deployed that way on the public network, and not many clients<br>support it (though Swift and Gajim both do, and they are<br>cross-platform).<br><br>Regards,<br>Matthew<br></body></html>