Dave Cridland wrote:
[snip]
*nod*
Might be a problem if a server requires EXTERNAL, but this is rare in
uncontrolled environments anyway.
That would make 0178 c2s-only and it could be merged with 0257 somehow.
That's possible. But then, 0178 should get merged with rfc3920bis.
That might be true for 0220 as well. Especially if we go for (3).
[snip]
"You're telling me the key is valid without checking it? Then you must
be lying."
But it makes no sense. If the remote end doesn't validate the key, but
authorizes you anyway, then you're authorized, and it doesn't matter
whether or not you think they did it right.
*nod*
No assumptions about how (and if) the receiving server asserts my
identity.
I think dialback was not designed to protect from that anyway.
Protect from what?
A receiving server who is not who he claims to be.
[snip]
There are two problems with that approach:
1) you do not know if the remote server is up and listening for
connections. See above.
2) an evil user on the remote system (other than the user who is
running the jabber server) who is able to open connection to
remote servers.
I do not think (2) is a real problem, especially not when certificates
are used.
If a trustworthy certificate is used, then we don't need to dialback,
certainly. (And trustworthy can mean "we've dialled back before and we
know this one"). Without that, then scenario (2) is possible.
So it's not really worth persuing that one.
Solving host security is not a XMPP problem, yes. I am not sure if the
slight protection that dialback offers against (2) is intentionally.
(1) is a problem anyway, so I think the answer to your question
"yes, but is tls really required?".
Philipp
