[Standards] Proposed XMPP Extension: Internet of Things - Discovery

Dave Cridland dave at cridland.net
Mon Apr 7 09:22:24 UTC 2014

On 7 April 2014 10:04, Philipp Hancke <fippo at goodadvice.pages.de> wrote:

> The alternative is we just say "Components are privately-authenticated S2S
>> connections", and invoke BiDi and SASL auth and make it happen. This is
>> functionally equivalent, but differs in that components are no longer
>> special in any way (aside from near-mandatory support for XEP-0288),
>> aren't
>> backwards compatible with the older protocol, which becomes obsolete. That
>> appeals to my sense of purity, and is likely significantly more secure in
>> a
>> number of ways. (At the very least, the security profile would be better
>> understood).
> Well, I think the primary differences are that
> a) components will appear in disco#items

I think that's orthogonal, actually - you could list ancilliary services
hosted on "full" S2S via disco#items as well. For example, a site might
choose to host their FT proxy or media relay on entirely different hosting
to their IM services.

So I suspect that while components are *often* listed, they're not always.

Besides which, my proposal isn't that components wouldn't need provisioning
of their own - it's just a protocol change, not a deployment one.

> b) a server won't attempt to connect to a component
That's not strictly true either, but again, I think you'd provision
components nonetheless - this is purely unifying the protocol. They'd need
to be provisioned, possibly given a password, and so on.

There's an implication here that a component *could* be connected to, as
well, but you'd obviously need to manually specify the endpoint in the
server's configuration.

However, by "moving on" from XEP-0114, we'd be able to reduce the attack
surface - it'd be no different to C2S/S2S from a security standpoint
(though possibly with additional considerations given "trusted" components
and allowed spoofing, etc).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140407/396add47/attachment.html>

More information about the Standards mailing list