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.
--
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
