ISSUE #3: Which hashing algorithms?
Discussion: As far as I can see, we had consensus not to mandate
any particular hashing algorithm, but instead to allow any
algorithm that is registered with the IANA [5]. Currently the
registered algorithms are md2, md5, sha-1, sha-224, sha-256,
sha-384, and sha-512. However, we seemed to have list consensus
that most people would use SHA-1 at the beginning (SHA-1 is the
default value of the 'hash' algorithm in the currently-approved
version 1.4 [3] of the spec), and perhaps switch to SHA-256 in the
future if it is shown that pre-image attacks (see RFC 4270) are
likely against SHA-1. That said, people *could* implement MD5 if
they want to because it is registered with the IANA.
Oh, goodness. I didn't notice that anything from IANA was
allowable. That's really an issue for me, because testing this is
going to be a major hassle.
Somehow, I had overlooked the 'any hash IANA recognizes' aspect as
well; for whatever reason, I had thought we were recommending SHA-1
and perhaps allowing MD5.
I also have some issues with this, because if you are free to
implement any hash that you want whatsoever, then everyone has to
implement EVERY hash that is registered with IANA, or else you lose
the entire purpose behind the hashing... i.e., being able to verify
that the hash indeed matches the returned list of features. At which
point, this is no more secure in practical terms than the original
0115 was.
I have no problem with the rest of the specification as it stands, but
I share the concern that this particular aspect will basically kill
interoperability, or at least completely nerf any advantage this
specification had over the original simpler form of caps.
So I see several questions:
3a. Do we specify an MTI algorithm or let the market decide?
If we don't specify MTI, I predict very low interoperability on this
feature, which is a fundamental building block for a lot of other
protocols. Anything more than 2 MTI algorithms will have a major
adverse effect on interop, and exactly one MTI algorithm would be
optimal for these purposes.
+1.
3b. If we specify an MTI algorithm, do we specify MD5 or SHA-1 or
something else?
Frankly, I don't care. MD5 is smaller, and probably more secure,
but has marketing issues, particularly with a vocal minority on this
list. We all have SHA-1 implementations for other things. Flip a
coin, for all I care.
+1 here as well, though I'd lean slightly in favor of SHA-1 just
because -- as Joe says -- we all already have SHA-1 in our clients for
other purposes. MD5's equally easy (and most of us probably have it
as well), but SHA-1 is pretty much guaranteed as other bits of XMPP
require it.
My conclusion: Specify an MTI algorithm and say it is SHA-1, but
allow other algorithms as registered with the IANA. If the market
leans heavily toward MD5 or SHA-256, consider (in the future!) a
change to the MTI algorithm by issuing an updated version of the
spec (after proper list discussion etc.).
Fine. With the additional caveat that anyone who uses a algorithm
that isn't MTI isn't likely to be able to interoperate.
Also +1.
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
