On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
Most protocol attacks are based on unexpected input. Attackers
wouldn't really care whether the values they send are registered or
usable in any way, as long as the attack succeeds. I don't think you
are proposing all caps handling entities ship with a copy of the
registry and fail on anything not included.
No, but we could potentially restrict input quite heavily.
Let's say that we add (yet) another attribute to the caps element,
indicating that the "new" restrictions are in place. (These might
include the various restrictions mentioned in this thread).
Now, when a client sees a caps marked as restricted, it can validate
the disco#info it gets.
If a client sees two caps strings, one marked as restricted and one
not, it should assume that the caps string is intended to be
restricted as proceed accordingly.
I'm also wondering if it's worth considering optional (and marked)
removal of XEP-0128 in cases where it's not used.
Of course, it may be simplest just to bite the bullet and switch hash
algorithm - or even change the 'hash' attribute name - because then
it'll get treated as a pre-1.4 caps by the vast majority of entities
and everything will happen right (or at least, no worse than it often
does today anyway).
I'm gradually leaning toward this, because although it's *quite*
violent, the downside is not impossible.
BTW, anyone any idea what happens if you include more than one <c/>
in a presence, in practical terms?
I know Miranda and Tkabber send software version. Probably many
others. Can we gather stats on jabber.org for this?
M-Link cannot capture that data, except by capturing all traffic
(which is inadvisable).
I would re-iterate that we still have no burning building. We're
getting closer, though.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
