[Standards] XEP-0115 redux

[Rachel Blackman]

>> 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 <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/