On 06/13/2013 10:18 AM, Peter Saint-Andre wrote:
On 6/13/13 8:40 AM, Matt Miller wrote:
On Jun 12, 2013, at 8:41 PM, Peter Saint-Andre
<[email protected]> 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 <[email protected]>
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 --> [email protected]" 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.
Yes, that is true, and I too don't want people to read more into the
results than is justified. I will keep that very much in mind as I
work on the next revision.
What I'd like to see is an extra attribute on each incoming stanza,
indicating that it was received via a protected s2s connection. Since
the attribute would be per-stanza, it doesn't have the race condition
problem of the hop check.
My use-case is I'm running a service that allows administration via
XMPP. Users may whitelist JIDs that should have access. The current
drawback with this approach is that it is not ultra secure. Someone
could conceivably make a dialback attack and act as someone else. My
plan is to add a checkbox to the administration config: "Only allow
administration from secure domains". The idea here is that an incoming
stanza would only be trusted if it was flagged as having arrived via
TLS-secured s2s, thus closing the dialback security hole. True, this
does not confirm that the user's client is using TLS, but I don't think
this is something I need to concern myself with. It would be the user's
responsibility to ensure nobody else can hijack his account (by always
using TLS, by using a good password, and by trusting the admin of his
server).
Just one attribute is needed for this, stamped on by the receiving
server. Perhaps it could be a SHIM header.
Maybe this should be in a different spec than the hop check. I just
wanted to bring up the idea here since I figure it fits the discussion.
It would provide some amount of tangible security without having to go
full-on e2e.
Justin
