On Mon Sep 5 18:51:16 2011, Waqas Hussain wrote:
On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland <[email protected]>
wrote:
> 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.
Disco extensions remain a sticky point, and I dislike forbidding '/'
in identity.name.
I think we could cope.
> 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.
That's a fairly interesting idea. More thinking required.
Right, it's not a fully fleshed-out solution, for sure.
> 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.
The transition should be smooth. I was initially for fixing the
current protocol, and would be for it if we found a good way to do
so.
We have sufficient pre-1.4 support out there to cope this way,
basically. I think any entity seeing pre-1.4 caps just doesn't verify
them at all, in practise.
> BTW, anyone any idea what happens if you include more than one
<c/> in a
> presence, in practical terms?
I suspect some would pick the first and some the last. That's the
two
kinds of child-element-scanning logic I've seen in clients. I don't
think we can depend on any behavior here.
Also, see last discussion about getting rid of order attribute in
privacy lists :)
Yup, I thought that might be the case.
>> 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).
Sad. I'd hoped there would be a way to dump the PEP caps table.
There possibly is, I think, but M-Link R14.6 ignores all non-+notify
features, and M-Link R15.0 ignores XEP-0128 (at least, without
disco-caching on).
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
