Re: Crypto agility in SCRAM + draft-josefsson-password-auth?

[ned+ietf-sasl@xxxxxxxxxxx]

> Chris Newman <Chris.Newman@xxxxxxx> writes:

> > --On March 21, 2008 12:50:26 -0400 Sam Hartman <hartmans-ietf@xxxxxxx>
> > wrote:
> >> I don't think md5 should be used for a new mechanism.
> >> Sha-1 is very widely available in C, Java and other languages.
> >> I think you may get significant pushback in ietf last call to the use of
> >> md5 in something new; I I know I'll be part of that.
> >
> >> From a theoretical security viewpoint, I would go with SHA-256 as
> >> it's best
> > available algorithm choice today.
> >
> > But a security mechanism that doesn't deploy provides zero incremental
> > security to the community regardless of how strong the theoretical
> > security happens to be.
> >
> > So I consider the question "will this deploy?" significantly more
> > important to the security of the mechanism than any particular choice
> > of algorithm. On that basis, any security algorithm that is widely
> > deployed and used in application-layer code (e.g. MD5, HMAC) has a big
> > advantage over algorithms that have not deployed in application-layer
> > code.
> >
> > I know MD5 won't be a deployment barrier.
> > I think SHA-1 won't be a deployment barrier.
> > I think SHA-256 will be a deployment barrier.
> >
> > So I presently lean towards SHA-1, but I'd like statements from likely
> > or potential implementers about the algorithms we're discussing.

> I would not implement a new protocol with MD5 in it at this point.

> Using HMAC-SHA-1 would be ok with me, although I would prefer
> HMAC-SHA-256.

> > SHA-256 isn't in my code toolkit, is not something I can code from
> > scratch and finding a cross-platform way to use it that's thread &
> > library safe and has a company approved OSS is not something I have
> > investigated.  I can't make a commitment until I investigate it.

> I suggest you read RFC 4648, and look at the source code provided in it.
> An implementation donated into the public domain is available from:
> <http://people.redhat.com/drepper/SHA-crypt.txt>.

You're missing the point. Of course Chris can read RFC 4648, or do a Google
search, or whatever, and dredge up some code implementing SHA-256. Anyone can
who isn't an idiot, and Chris is no idiot.

The problem is that finding the necessary code, building it, testing it,
integrating it into a complex product environment, is a nonnegligable amount of
work. And that's just for a straightforward product integration exercise - it
gets a lot more fun once you factor in support for crypto acceleration
hardware, or support for special processor instructions for better performance.

I get all this stuff for free, including hardware acceleration support, for MD5
and SHA-1 from multiple existing toolkits. Support for SHA-256 is much more
limited, and that, like it or not, is a barrier to deployment.

				Ned