[Standards] XEP-0115 redux

[Joe Hildebrand]

On Jan 9, 2008, at 4:14 PM, Peter Saint-Andre wrote:

> OK folks, it seems that we're not quite there on XEP-0115 (Entity  
> Capabilities), or at least that some people (especially important  
> people with votes on the XMPP Council ;-) don't quite understand the  
> logic behind certain aspects of what we agreed to on the list.

It seems as if they might have posted to the list as a part of that  
discussion, then.

> ISSUE #1: Do we need a new namespace?
>
> My conclusion: I am opposed to defining a new namespace.

As am I.

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

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

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

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

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

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

-- 
Joe Hildebrand