On Mon Sep 12 22:22:01 2011, Peter Saint-Andre wrote:
One way to solve this problem is to define a new algorithm, either
in a
revision to XEP-0115 or in a new spec with a new namespace. To
conserve
space in presence, we'd prefer to avoid a new namespace. So that it
is
possible to continue using the vast majority of existing caps
hashes,
we'd prefer to keep the algorithm the same, if that can be
accomplished
in a secure way.
I sympathize. I really do. I'm also less than convinced it's an
achievable goal.
We thought of another approach, which has two parts...
I think both parts are massively warty.
<feature var='!'/>
OK. The problem here is that this is not a change in XEP-0115, it's a
change in XEP-0030, and as such has wider ramifications.
Any software supporting this approach would need to advertise
support
for the first-sorted disco feature. If an application processes a
caps
input string that *not* contain the first-sorted feature, based on
local
service policy it could either reject it as an attack or accept it
as
using the old-style caps algorithm. (Eventually everyone would
regard it
as an attack, but that might not happen for a few years.)
It's only an attack if you're doing XEP-0115 expansion, rather than
processing XEP-0030 in isolation. But I'm concerned that it means
that if you want to do XEP-0030 anywhere, you'll need to add in '!',
either in order to prevent an interop failure when someone rejects
your feature list, or to cope with future XEP-0115 cases.
We then legislate that XEP-0128 extensions MUST use this FORM_TYPE
(this
is not a major imposition since there is very little use of
XEP-0128 in
the wild). Here again, if an application processes an input string
that
contains a FORM_TYPE other than "urn:xmpp:clarkform", based on local
service policy it could either reject it as an attack or accept it
as
using the old-style caps algorithm.
I think this is a radical change which has a large effect on existing
uses.
- XEP-0128 *is* used very heavily in the wild, just not (we think)
for client capabilities. MUC rooms use this (and there are many
consumers), to give one example.
- The FORM_TYPE is used to distinguish between sets of metadata; I
think forcing all FORM_TYPEs used to be the same would effectively
mean that only one XEP-0128 extension could be used, and whilst I
cannot think of a case where this would have problems, I'm not
convinced there isn't either.
I do want this to work; I'm not convinced it's enough, or right, and
I do think it'll land us with a number of warts in the protocol that
we're still in a position to avoid.
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
