On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/6/13 6:40 AM, Matthew Wild wrote: >> On 6 June 2013 10:21, Simon Tennant <si...@buddycloud.com> wrote: >>> End to end encryption is a worth goal. This is very cool for >>> getting information on the s2s connection. >> >> Perhaps on first sight. However this kind of usage is exactly why >> the XEP died last time around. It isn't suitable for anything >> except purely informational/debugging purposes. This is because the >> link can change - it might be encrypted when you check it, and then >> reconnect unencrypted without you knowing. Also, malicious entities >> can always lie. > > What I'd like is to know whether the connection from my personal IM > server (stpeter.im) or my company's IM server (say, cisco.com) to a > random server like prosody.im or jabber.ietf.org is encrypted. Sure, > malicious entities can lie, but I try not to create accounts or > authenticate with malicious servers. :-) Look, I need to have *some* > level of trust in the server I authenticate with. I just want to know > if the path from there to the next server is encrypted, too. If I'm a > server admin presumably I have some kind of server-side tool I can > use, but that's not the case if I'm not an admin. I don't disagree that the user is trusting their server by logging in. And if this check were to stop at "my.domain --> other.domain", then I can see some confidence in the results because of the trust. Changes in the state *could* be dealt with by making this information available in a pubsub-like manner (I sensed the collective shudder from some of our server developers and operators before I even typed that sentence (-: ). However, that trust doesn't carry over to the answer for "other.domain --> contact@other.domain" which users will want so very, very desperately. I don't necessarily have a problem with this as a protocol-level diagnostic tool; it can help users (or rather, the developers of the client the user interacts with) and admins to troubleshoot. But the potential of abuse and over-interpretation is extremely high. - m&m Matthew A. Miller < http://goo.gl/LK55L >
smime.p7s
Description: S/MIME cryptographic signature
