[Standards] various rfc3920bis feedback

Philipp Hancke fippo at goodadvice.pages.de
Tue Feb 24 12:07:16 UTC 2009


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



More information about the Standards mailing list