[Standards] XEP-0115 redux

[Peter Saint-Andre]

Joe Hildebrand wrote:
> On Jan 9, 2008, at 4:14 PM, Peter Saint-Andre wrote:
> 
>> ISSUE #2: Should the 'v' attribute be REQUIRED?
>>
>> My conclusion: Leave version 1.5 [4] as it is now, with 'v' 
>> RECOMMENDED but *not* REQUIRED. (In fact I would not object to making 
>> it OPTIONAL, but RECOMMENDED seems closest to the prior list consensus.)
> 
> I don't care about this, unless we want to use the presence of the v 
> attribute to denote that we're doing new-style, and we hard-code the 
> hash algorithm.  That's not going to happen, so RECOMMENDED is fine; it 
> would make me happy if there was a sentence like:
> 
> "If the v= attribute is not present, the receiver MUST assume that the 
> version is intended to be private, and MUST NOT send any other 
> version-discovery protocol to the sender automatically."

+1, that's good.

I don't think it's a good idea to make 'v' REQUIRED because some people 
may not want to expose the version (for legitimate or assumed security 
reasons). In fact you might not want to make the 'node' a URL to the 
product website either (the hash combination could effectively mask 
entire which software you're using).

>> 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.

Er, yes. I thought about that as I was writing my previous message.

>> 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.

IMHO it's always best to have one MTI.

>> 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.

The statement "we all have SHA-1 implementations" provides a good 
argument for specifying SHA-1 as MTI. Code reuse and all that.

If SHA-1 is found to be vulnerable to pre-image (*not* collision) 
attacks at some point in the future and those hypothetical pre-image 
attacks are found to be potentially practical, then we should strongly 
consider adding some other hashing algorithm to the MTI list or swapping 
out SHA-1 for something else. But that day may be so far off that some 
new hashing algorithm will be available by then (e.g., not something in 
the SHA family at all).

>> 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.

Correct.

>> On a more general note, I think we have had list consensus on Issue #3 
>> for at least a few weeks now, on Issue #2 for about 2 months, and on 
>> Issue #1 for 6+ months. Not everyone was happy with the consensus, but 
>> everyone who participated in the list discussion agreed to give a 
>> little bit in order to reach consensus.
>>
>> My final conclusion is that we need to accept the list consensus and 
>> move on. We have ensured backwards-compatibility, minimized network 
>> impact, improved security, and met the other requirements of the 
>> specification. You may not be in love with the final product, but 
>> sometimes consensus is rougher than others. Let's get this done, and 
>> soon, because people need to code against these specs (e.g., for 
>> compliance with the "XMPP Basic Client 2008" level specified in 
>> XEP-0211).
> 
> +1.  Anyone that wants to take issue with the list consensus should do 
> so loudly, publicly, and expeditiously.

You betcha!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080109/6500a3b6/attachment-0001.bin