[Standards] Re: [jdev] XEP-0115: Entity Capabilities
dave at cridland.net
Tue Jul 3 22:01:42 UTC 2007
On Tue Jul 3 22:04:41 2007, Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> I also agree with Dave that we want to future-proof
>> this. What if 3 years from now we want to use SHA-256 and 7 years
>> now we want to use an algorithm that emerges from the current NIST
The "It's Really Secure This Time Hash Algorithm", FIPS PUB 180-3?
>> It might be good to include a 'hash' attribute whose value is one
>> the hash function text names from the IANA registry (but the value
>> defaults to MD5 or whatever we settle on now so that you don't
>> have to
>> include it until we decide to allow alternate algorithms).
> +1 If we want to prevent malicious cache poisoning going forward,
> then clients need to be able to upgrade the hash they are using.
> MD5 is not secure enough even for this purpose. (I've read about
> attacks that require less than an hour of computing time!) IMHO,
> SHA256 is the most reasonable default.
Less than an hour astonishes me, actually. I suspect that stringent
input formatting would preclude this - it's not good enough to find
*a* collision, you need a collision that has benefit to the attacker,
What about compromising on SHA-1 - possible to mount a collision
attack in 2^63 operations, last I read, which is still technically a
weakness, but not one I'd lose sleep over for this data. On the other
hand, it's been examined more than SHA-256 anyway, and it's 96 bits
shorter. (Or only 4 more octets of base64 compared to MD5).
>>> 2) do we need ext in the hash world?
>>> Rachel makes a good point that without ext, more data has to be
>>> since there will be redundant features associated with different
>>> ver's. I think it's a toss-up; no ext's is considerably simpler
>>> for all
>>> involved; no partitioning of features on the sender side and no
>>> on the receiving side.
>> I don't think we need 'ext' in the hash world.
> +1 the protocol is far simpler to implement without extensions.
> More storage will be required. But I'm not sure that we'll hit the
> sweet spot for storage-challenged clients. i.e. It may well be that
> those clients that have insufficient storage to cache the hash for
> each combination of plugins also have insufficient storage to cache
> hashes for each separate extension (i.e. they can't use caps at
I don't think that storage is an issue, for the reasons you give
above. I'd be somewhat more concerned with the number of network
probes required. In principle, though, it should remain one
round-trip whatever happens, it's just a count-the-octets issue.
Having thought about it for a bit, I suspect having ext will probably
cost more octets to send the ext than you'd save by caching the
results of disco on the ext hashes.
This changes, however, if XEPs were written such that, for example,
fixed hashes provided XEP-0211 in ver, and the additional features of
XEP-0213 in one or more ext values. Then, the featuresets indicated
by the hashes could even be preprogrammed into clients for reasonable
[On using caps for automatic client indentifications]
> Hmm, going forward, are the clients that most people use going to
> continue showing these icons? Is this a feature we need to care
> about? Even though I'm one of the small group of people involved in
> the XMPP community, I really don't care what client my contacts are
> using. Will there ever be mass demand for this feature? On the rare
> occasions where people are interested, they'll probably be
> perfectly happy to explicitly ask their client to find out the
> other user's client version on a case-by-case basis.
I have to admit, the only times I've wondered what client someone's
using, I've asked them directly. You know, using the wetware layer.
"What client are you using?". It's an old fashioned way of doing it,
but it works really well, and gets you quite a bit of additional
I suppose this new fangled version thing would work okay, too,
there's no pressing need for me to know, though, most of the time.
However... I hate to lose potential functionality out of a protocol -
it feels wrong. I've no better argument than that, though.
> IMHO the 'node' attribute could be repurposed to be the name of the
> hash function (for backwards compatibility). We could also add some
> language to the XEP stating that clients SHOULD NOT perform an
> iq:version flood. (IMHO, assuming the features hash is available
> via caps, there is little justification for such behavior.)
Well, we *do* lose versions. Versions become abstracted, so it
becomes a case of knowing that I use SuperMegaJabberClient
automatically, but you'd need to do an iq lookup to know what
version. On the other hand, if I upgrade, and the new version doesn't
add any new features, there's no re-querying for new featuresets.
> Dave Cridland wrote:
>> Assuming you didn't really mean base64, since hashes are typically
>> represented as strings simply as hex digits. Base64 would be
>> smaller, but unusual, and potentially include character-space
>> clashes with Disco.
> I did mean base64, but if people think that is too hard to
> implement, then hex is fine (even though it is 50% longer). I don't
> understand how base64 could create clashes with Disco.
It's got "/" in it, which vaguely unnerves me. If that's not an
issue, that's fine.
Ironically, the next thing I did after writing that was review the
new/old SCRAM-* SASL mechanism family, which does use base64 encoded
hash algorithm outputs, so I'll just shrug my shoulders at this
Base64's fine, recognisable, etc, so I'll retract that, and we can
agree that I was wrong and you're right. Normal arrogance and
infallibility to be resumed on Wednesday. Unless it turns out later
that I'm right, in which case, I'll deny everything, and say I told
you so. ;-)
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards