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 from
now we want to use an algorithm that emerges from the current NIST work?
It might be good to include a 'hash' attribute whose value is one of
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.
2) do we need ext in the hash world?
Rachel makes a good point that without ext, more data has to be cached,
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 unions
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 all).
Joe Hildebrand wrote:
On Jul 3, 2007, at 6:48 AM, Ian Paterson wrote:
Rachel Blackman wrote:
Let's say we have node='http://ceruleanstudios.com/astra/caps' and
ver='h$someverylongstring' and ext='h$otherverylongstring'
Or how about simply:
node='$' ver='base64encodedHashOfFeatures'
No. The other reason for caps is so that receivers can show a different
icon for each different client that they have received presence from.
There has to be a URI to define the sending client.
Yes, that cuts down on the old iq:version flood. Or so we hope. :)
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.
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.)
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.
- Ian
