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
from
now we want to use an algorithm that emerges from the current NIST
work?
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
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.
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,
after all.
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
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).
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
benefit.
[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
freeform metadata.
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
point. :-)
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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
