[Standards] XEP-0115 redux

[Peter Saint-Andre]

Dave Cridland wrote:
>> ISSUE #2: Should the 'v' attribute be REQUIRED?
>>
>> Description: The 'ver' attribute was REQUIRED in version 1.3 [2] of 
>> the spec. In a late change made to version 1.4 [3] of the spec during 
>> the Council meeting at which version 1.4 was approved, we suggested 
>> that the value of the 'node' should be "ProductURL#ProductVersion" 
>> (e.g., "http://psi-im.org/#0.11") but we agreed that this would *not* 
>> be REQUIRED or even officially RECOMMENDED. In the proposed version 
>> 1.5 [4] of the spec, we added a new attribute 'v' to encapsulate the 
>> software version, but it is only RECOMMENDED, *not* REQUIRED.
>>
>> Discussion: Some people on the list objected strenuously to the late 
>> change made to version 1.4 [3] which suggested that the 'node' 
>> attribute should encapsulate the ProductVersion. Therefore the list 
>> consensus was that the 'node' attribute should be the ProductURL not 
>> including the ProductVersion, and that we would define a new attribute 
>> 'v' to communicate the ProductVersion; however, the list consensus was 
>> that this attribute would *not* be REQUIRED but instead only 
>> RECOMMENDED (some people argued for making it OPTIONAL or removing it 
>> altogether, but we settled on RECOMMENDED).
>>
>> 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.)
>>
>>
> Conflicting arguments here. As a not-really-client developer (I do have 
> a client, but even I don't use it), I hold no strong opinion.
> 
> 1) The old spec did have a version, held in ver, so the new version is 
> to this extent a regression.
> 
> 2) Exposing your client software version is a potential security issue.
> 
> If I had to state an opinion, I'd say that if you wanted to hide your 
> software version in "Classic" XEP-0115, it was pretty easy to obfuscate 
> the ver attribute, whereas making v optional (whether OPTIONAL or 
> RECOMMENDED) does at least make this choice explicit.

I shall take that as a (tepid?) vote for RECOMMENDED. :)

>> ISSUE #3: Which hashing algorithms?
>>
>> Description: The Council discussion seemed to assume that version 1.5 
>> [4] says SHA-1 is mandatory-to-implement ("MTI"). In fact, version 1.5 
>> does not mandate implementation of any specific algorithm. Be that as 
>> it may, some Council members suggested that we recommend MD5 instead 
>> of SHA-1 (the only concrete reason I heard in the meeting is that MD5 
>> output is smaller).
>>
>>
> (Kind of. One issue is that MD5 might actually be more secure.)

Well, it's an open question what the security properties of entity 
capabilities really are, but be that as it may...

>> 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.
>>
>>
> Note that RFC4270 was a fairly extensive survey by an experienced IETF 
> security chap - Paul Hoffman runs the VPN Consortium - and Bruce 
> Schneier's name ought to be familiar to people interested in crypto and 
> security.
> 
> Note also that whilst it describes some progress made in preimage 
> weaknesses in SHA-1, none are mentioned for either SHA-2 (That's 
> SHA-256, SHA-512, etc), or MD5. MD5 has had a lot of cryptanalysis - 
> you'll note that more researchers are producing papers on it than any 
> other hash algorithm, and this isn't entirely down to relative strength 
> compared to SHA-* - it's more down to the fact that MD5 has considerably 
> larger deployment, and so is a more attractive hash to analyse.
> 
> The fact that after this length of time, nobody appears to have found a 
> preimage attack on it is pretty gratifying. MD5 *is* demonstrably weak 
> in two areas:
> 
> 1) Challenge-Response password hashing, for example in CRAM-MD5. Not 
> because of a mathematical weakness, but because you can brute force 
> things too fast, across the entire, fairly limited, space of a password. 
> This doesn't affect us for the twin reasons that:
> 
> a) Our space is much bigger.
> b) The space we have is quite rigid in format.
> 
> 2) Collisions, and from there signature algorithms. This is where you 
> come up with two inputs that produce an identical output. This is useful 
> if:
> 
> a) You get to choose both inputs. (Our poisoner cannot).
> b) There is scope for adding random junk somewhere. (Likewise).
> 
> In theory, you can do a collision without random junk, but it would take 
> considerably longer. Also important to note is that this has no impact 
> on whether we're more likely to find inadvertant collisions with MD5. In 
> theory, the shorter hash length will have an impact, simply by the 
> birthday "paradox", but it's still pretty rare.
> 
> But it's not weak in preimage attacks - those where the attacker knows 
> the hash, and/or the input, and wishes to construct an alternate input 
> of their choosing which matches.
> 
> In order to perform caps poisoning with MD5, therefore, the attacker must:

Is this also true of SHA-1, or only of MD5?

> i) Subvert the development process of the client.
> ii) Optionally, to cover his tracks, subvert the XSF, thus allowing the 
> attacker to have some control over what counts as legitimate input, thus 
> reducing, to a degree, the random junk problem.
> 
> You'll note that Kevin Smith is in a position to do both, but no other 
> person or entity is, throughout the entire world.

The clear conclusion is that we must remove Kevin Smith from all 
positions of authority. :)

> And anyone in either position is capable of inflicting a significantly 
> higher damage by choosing to do some easier attack - if the developer of 
> your client turns out to be an Evil Genius, you're henceforth Doomed. 
> Similarly, if Council members wish to subtley undermine your security, 
> we are in a position to do that.

As far as I can see, any particular Council member would not have much 
power on their own. Now the XMPP Registrar might be another story...

>> 3a. Do we specify an MTI algorithm or let the market decide?
>>
>>
> I think we need an MTI, I have to admit I'd read the current text as 
> essentially stating that SHA-1 was the MTI.

That is what developers have understood so far (it should have been 
written as an MTI in the first place).

>> 3b. If we specify an MTI algorithm, do we specify MD5 or SHA-1 or 
>> something else?
> 
> What concerns me is not that SHA-1 is a particularly poor choice, but 
> that we may have reached that choice by applying faulty logic. SHA-1 
> does appear to have *some* weakness in preimage. I don't know if, given 
> the similarity between SHA-1 and SHA-2, this also applies there, but I 
> cannot find any mention of preimage weakness in MD5.

RFC 4270 says:

    All the currently known practical or almost-practical attacks on MD5
    and SHA-1 are collision attacks.  This is fortunate: significant
    first- and second-preimage attacks on a hash algorithm would be much
    more devastating in the real world than collision attacks, as
    described later in this document.

Has the situation changed since that was published in November 2005?

> I'll drop my objection if people want - in fact, I'll drop it if the 
> other two issues are resolved, 

Which other two? As far as I can see the namespace issue is off the 
table anyway, so our remaining issues are the 'v' attribute and the MTI 
algorithm.

> but I would like people to take the 
> opportunity to satisfy themselves that they've made the right choice in 
> the face of the evidence.
> 
> So, some reading:
> 
> 1) RFC4270 is an excellent backgrounder on the different attacks on 
> hashes, and how these affect real-world protocols.
> 
> 2) Wikipædia is helpful, too:

You can't trust Wikipedia. Someone might have subverted those pages!

> http://en.wikipedia.org/wiki/Birthday_attack demonstrates that we need 
> around 2.2 x 10^19 possible inputs for MD5 before an inadvertant 
> collision is more likely than 50%, assuming that these are randomly 
> spread. (They aren't, so this is in effect a worst case).

And how many for SHA-1?

> http://en.wikipedia.org/wiki/Preimage_attack, 
> http://en.wikipedia.org/wiki/Cryptographic_hash_function, both give 
> detailed background.

I reiterate what I said in November...

http://mail.jabber.org/pipermail/standards/2007-November/017282.html

All of these preimage attacks seem unlikely given the small universe of 
possible inputs to the hash function that could serve as caps poisoning 
(i.e., concatenations of disco identities and disco features). Even if 
preimage attacks are shown to be possible against SHA-1 or MD5 or any 
other algorithm we might consider, I still don't see that such attacks 
would be practical in our context.

The XMPP Registrar previously offered to pre-generate all the possible 
hashes (where "possible" is determined by all the possible combinations 
of service discovery identities and service discovery features). Would 
that help or hurt? At least it would give us some idea of the possible 
hashes and therefore help white hat attackers try to find preimage attacks.

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/20080110/c0fd9855/attachment-0001.bin