[Standards] Hash algorithms (Bits of Binary / Jingle FT)

Dave Cridland 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  
> protocols:
> >
> >  
> http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml
> Yes, I think it's best for us to use the names from that IANA  
> registry,
> 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  
> change
> > that if needs be. (And would have support, I think).
> What do you want to update there? The hash function names, or the  
> name
> 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  
> *cough*)
> >> as well as MTI recommendations (perhaps choosing SHA-256, as NIST
> >> recommends [3]).
> >
> > 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  
> sane
> > 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  
> we'll
> 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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list