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.
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.
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.
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]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
