[Standards-JIG] Was: JEP-0165. Now: selective s2s depending on version?

Andreas van Cranenburgh andreas at unstable.nl
Thu Nov 17 12:40:39 UTC 2005


On Thu, Nov 17, 2005 at 11:38:54AM +0100, Matthias Wimmer wrote:
> [...snip: potentially serious security problem?]

It occurs to me that a quick solution to this could be that every server
can enforce what servers it connects with. Eg. s2s MUST be XMPP 1.0, and
MUST be SSL/TLS + SASL. And here comes the thing I'm not sure about:
also the version of the specific implementation could be matched, and
selectively allowed. Since arbitrary versions could have security problems.

The point:

- I suppose you could already do this, by allowing s2s, and then closing
  the connection properly, if a version request yields a "disfavoured"
  version. But maybe it's a better idea to have it in the s2s handshake,
  properly? Or eh, am I missing an X number of existing standards?
  Probably.

- Maybe rather an informative JEP to explain the practice to jabber
  admins? I should follow-up if ejabberd ACL's are up to this idea,
  and I welcome follow-ups regarding any other implementations (which I
  don't know well or at all). If that output is at all positive, I see
  reason to write a general doc (preferrably implemantation agnostic),
  explaining why it's a good idea and explaining what kind of threat
  levels there are, and good references etc.
  A JEP would be a good base of this, and then the database of security
  problems should of course be somewhere else -- maintained by each
  implementor themselve(s), hopefully :) (at least for open source this
  is not a weird choice, you can audit most everything anyway, at will)
  
Eg. personally I'd like said policy, so that I can block servers that
are known not to stringprep (sp?) properly. Security comes before
interoperability for me, though within reason. Also, naturally I'd block
any jabberd below 1.4.3 . . . The list goes on, AFAIK :)

Also, this "enforcing" or "selective s2s" would be an extra urge to
server developers to finally fix their code! stringprep is trivial (ie.
code is readily available), as far as I can tell :) And don't get me
started on TLS over s2s, of course, XMPP-1.0 was published how long ago?
[...]

Conclusion:

Anyway, this should also go to the xmppnet list, I suppose; and/or to
JADMIN. But I don't like cross-posting, so let's just start with the
question if it would work with current standards, or if any sort of JEP
should be written? 

[BTW: I have zero standards writing experience...  but well, if there's
enthusiasm and a need, I just might -- *after* deploying it on my
testing and live server though! The worst thing is standards that merely
collect dust, but not any serious implementations, with Jabber -- all
IMHO. ]

-- 
        Andreas        [ http://unstable.nl | xmpp:andreas at unstable.nl ]
                       [  callto:ils.seconix.com/andreas at unstable.nl   ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20051117/43638285/attachment.sig>


More information about the Standards mailing list