On 4 February 2015 at 21:29, Kevin Smith <[email protected]> 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.
