On Sep 13, 2011, at 03:57, Dave Cridland wrote: > 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. >
Can you expand on this? I must be missing something, but I don't see how the lack of a '!' feature in, say, a MUC service's disco#info result means it's rejected. Also, what does 'rejected' mean in terms of XEP-0030 but *not* in terms of XEP-0115? >> 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. > The intent was not every place XEP-0128 is used, but where XEP-0128 is used in conjunction with XEP-0115. I will admit that this change is the most bothersome to me, too. > 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. > I've been thinking of something that might be a less-awful compromise. I'll post to this list about it soon for us all to mock and ridicule (-: - m&m <http://goo.gl/voEzk>
smime.p7s
Description: S/MIME cryptographic signature
