Hi Peter, On 03 Apr 2014, at 14:03, Peter Waher <peter.wa...@clayster.com> wrote:
> Hello Edwin & Co. > >> You seem to confuse Historical with Deprecated. Although the XEP is >> historical, the status is active. Furthermore, all servers I have used so >> far support XEP-0114: this is a core feature of most implementations. > > Actually, I do not. I am aware of the difference. What historical tells me, > apart from it being historical, i.e. part of the Jabber project before being > formalized, is that it: > > * Is not sufficiently important to have been lifted and issues discussed and > fixed, to become draft or final (or RFC). > * Any changes to it are not guaranteed to be backwards compatible. > * It's future is unclear, which is also stated in the XEP. > * It's use and implementation variants are unclear. > * Security aspects are unclear. > * It is not recommended by XSF or xmpp.org anywhere. > > After having investigated XEP-0114 now in some more detail, there are various > aspects which concerns me. Since Jabber components seems to be a third way to > connect to an XMPP server (the other two being c2s and s2s), and a very > useful one at that I must agree, I think the XSF should take some time and > effort in formalizing this XEP a bit, and fixing some of its flaws. I'm told > that it uses an old version of XMPP (0.9), and I wonder if it is not in > everybody's interest to lift it to v1.0, and allow things such as starttls, > etc. to make it more secure. Today, there is no way for the client > (component) to validate that the server is who it pretends to be, which makes > MITM attacks quite easy. And since you get such a direct access to the > server, it looks very much like a backdoor to me. I completely agree about making XEP-0114 (external components) more suitable and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage would be great, but would also break a lot of implementations. > > Best regards, > Peter Waher -Cheers /Steffen
smime.p7s
Description: S/MIME cryptographic signature
