[Standards] [Council] component-s2s

Dave Cridland dave at cridland.net
Wed Feb 4 21:57:41 UTC 2015


On 4 February 2015 at 21:29, Kevin Smith <kevin.smith at isode.com> wrote:

>  I’m -1 on the component-s2s spec. I’ve been backwards and forwards a
> number of times on whether to use the veto or not, and I’m using it in the
> lightest sense.
>
>
I'll elide the flame war if that's OK? I appreciate it's traditional, but...

Anyway, a link to the inbox XEP for those that haven't read it yet:

http://xmpp.org/extensions/inbox/s2s-components.html


> I think we should have a wider discussion before we publish an experiment
> to replace the existing historical and ST component XEPs with this. If
> discussion leads to a generally positive results, that’s all I’ll need to
> accept it.
>
>
Right, it's an interesting case - it's clearly duplicating existing XEPs,
which is generally held as an exemplar reason to veto a XEP. The existence
of '225 indicates there are issues with '114, but the continued use of '114
over '225 suggests the advantages of '225 are insufficient.


> My current thoughts are that this is re-using S2S (good) but in such a way
> as to require special-casing anyway (reducing the utility of reuse), and
> that requiring the TLS auth and bidi makes the potential attack surface
> here a little higher than I’d like (bidi hasn’t had great success of
> successful implementations).
>
>
I suspect that when I sketched out the idea, the special cases involved
weren't really clear in my head.

For one thing, I chose to signal the component-ness of the session using a
special 'to' domain. My gut feeling is that it's wrong, actually, but I
can't think of anything better.

For another, I essentially suggest that authentication and authorization of
the stream is special-cased. This is problematic, because I only really
specified (and therefore thought properly about) the initial case, and
sketched over the piggybacking, and didn't consider the host server's
authentication to the component at all.

Now I think the reuse of TLS here is fine, and I don't think there's an
alternative to BiDi - and I'd love to see that better used anyway.

However, if we don't think that there are going to be architecturally clean
solutions to the authentication/authorization, then this design is broken
and cannot be fixed, and good on you for calling me on it.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150204/5508d679/attachment.html>


More information about the Standards mailing list