On Mon, Sep 21, 2009 at 2:16 PM, Dave Cridland <[email protected]> wrote:
> Waqas - thanks for driving this. > > On Fri Sep 18 15:02:04 2009, Waqas Hussain wrote: > >> 1. The Current XEP needs to be changed. >> > > I said it in San José, but I'm not sure it ever went to the list, so I'll > repeat this here: > > There is no burning building. > > We have an attack, yes, and this attack can occlude features. And we need > to solve these attacks, too. But... the only use we thought of in San José > was to occlude, say, esessions or XTLS, and these are sufficiently low in > deployment levels that I'm willing to entertain lots of options on this > rather than rush into anything. I agree completely. The current deployment and usage patterns are not seriously affected. We can take our time and do it right. > 2. Changing it while keeping backwards compatibility is not feasible >> (IMHO). >> > > I think we can close a considerable number of holes. I've not yet > investigated your comments about whether this is all of them in detail yet, > but I do agree that what these do is add considerable complexity - and > hackery - to the C14N algorithm, and I'll accept that they may not solve all > the problems. As far as I can see, we can reduce the attack surface to some extent while staying backwards compatible, but it's next to impossible to eliminate it. > 3. Changing it without keeping backwards compatibility has a significant >> cost: Software needs to implement it AND a high bandwidth cost during >> transition. >> > > This is the one that worries me most. > > When we designed "New Caps", we specifically added in hash agility. My > initial suggestion was to use hash agility to solve this - we have the > ability to change algorithm, and although we'd previously - rather foolishly > - considered only the possibility that the cryptographic hash function would > be compromised - we, of course, design things far better than those crypto > fellas - the same mechanisms should apply in exactly the same way. > > And they do - and yet they're not solving the problem they were designed to > do. > > Ooops. > > This means that if a preimage is found against SHA-1 - and my understanding > is that SHA-1 preimages are about the same state as MD5 preimages, currently > - we will not be able to migrate to SHA-512, or - given that SHA-512 will > likely be affected too - some other hash function, without considerable > cost. > > So, on the one hand, I agree on reflection that this is out as an option. > On the other, it highlights a whole class of potentially nasty problems. Yeah, oops. I can feel good about not being involved in that design ;) I'm thinking of something along these lines: <c xmlns='urn:xmpp:caps'> <h name='sha-1'>QgayPKawpkPSDYmwT/WM94uAlu0=</h> </c> Multiple <h/> elements leave the door open for future expansion. Also worth considering is whether multiple hashes for different sets of data make sense instead of just one. A hash for capabilities of an entity is the most basic. A hash for software ID and version (disco#meta?). A hash for disco#items. Future XEPs being able to define hashes for datasets they define is also useful. The downside is a slightly larger presence packet (which is mitigated by the caps optimization), but I see this leading to a significant reduction in queries. Just putting my half-formed thoughts out there for consideration. > 4. A new XEP has a cost: Software needs to implement it. >> >> Conclusion: A new XEP (which can work in parallel with the old until the >> old >> is phased out) is the least cost option. >> > > I'm not sure it's the least cost, but it has the ability that we can design > for hash agility from the start, based on the experience we've had so far, > and do so without damaging the current XEP, too. It's far easier to throw > away a new XEP if it doesn't work out - which is, I admit, a demotivator to > work on it, but as a practical matter, a new XEP is very low risk, and > potentially higher reward. > > Dave. > -- > Dave Cridland - mailto:[email protected] - > xmpp:[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 > -- Waqas Hussain
