[Standards] Hash algorithms (Bits of Binary / Jingle FT)
dave at cridland.net
Tue Aug 17 08:17:38 UTC 2010
On Tue Aug 17 03:58:12 2010, Peter Saint-Andre wrote:
> On 6/29/10 2:27 PM, Dave Cridland wrote:
> > There's an IANA registry, which we've generally used in recent
> Yes, I think it's best for us to use the names from that IANA
> and to grandfather older usages.
Yes, it seems like the way to go.
> > Slightly awkwardly, this relates to X.509 defined hashes, so
> would be
> > tricky to update, but an IETF standards action could probably
> > that if needs be. (And would have support, I think).
> What do you want to update there? The hash function names, or the
> of the registry?
The purpose of it, and the registration procedure, really.
Currently, one could only introduce hashes which had an application
within X.509, and specifically, as an update to RFC 3279, which is
what I meant by it being tricky. A single registry of hash function
text names is, I think, now demonstrably a good idea, and the
restriction on it of being only updatable in that context strikes me
as less than useful.
But this is IETF stuff. Know anyone in IETF-land?
> >> 5) Should the XSF adopt hash-function recommendations and
> standards for
> >> all future specs? I'm thinking standardized names (*cough* #1
> >> as well as MTI recommendations (perhaps choosing SHA-256, as NIST
> >> recommends ).
> > There's several uses for hash algorithms - some use-cases demand
> that a
> > preimage attack be impossible, some don't, for example. The safest
> > option for us is to pick a single algorithm - this also has the
> > advantage of simplifying implementation requirements.
> > I've said before in IETF-land that a single spec of "this is the
> > MTI security algorithm" would be useful. Perhaps the XSF could
> show them
> > how it's done.
> However, such a spec is no substitute for hash agility, because
> need to update the MTI recommendation in the future.
Oh, absolutely. There's just considerable benefit in updating the MTI
for all protocols in lock-step, I think.
Otherwise, we end up in the case where to implement a mail client,
for instance, each protocol demands a different authentication
mechanism, even though every protocol uses SASL. Which is insane.
In XSF-land, we're really restricted to hash algorithms in scope -
everything else is a single case (SASL, TLS cipher suites, etc).
I'll raise this on ietf-politics and see whether it spawns an endless
and inconclusive thread.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards