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

From: Chris Newman <[email-masked]>
Date: Mon, 24 Mar 2008 18:16:18 -0700

--On March 21, 2008 12:50:26 -0400 Sam Hartman <[email-masked]> 
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.  Here's my 
statement as an implementer:

I can commit to implementing this mechanism if it uses any combination of 
HMAC, MD5, SHA-1, iterated-hash, or PBKDF-2.  I can not commit to 
implementing this mechanism if it uses 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.

		- Chris

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Mar 2008 11:36:16 +0100

Chris Newman <[email-masked]> writes:

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

/Simon

---

From: [email-masked]
Date: Thu, 27 Mar 2008 12:03:48 -0700 (PDT)

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Mar 2008 22:58:29 +0100

Maybe we can short-circuit this discussion.  Given the trade-offs here,
I propose to use HMAC-SHA-1.  Would you or anyone else object to that?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 27 Mar 2008 17:22:40 -0500

On Thu, Mar 27, 2008 at 10:58:29PM +0100, Simon Josefsson wrote:
> I propose to use HMAC-SHA-1.

+1

Make that the required to implement algorithm.  Also provide for
HMAC-SHA-256.  Then we can later (years later) update the spec to
require HMAC-SHA-256.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 27 Mar 2008 23:32:36 +0100

Nicolas Williams <[email-masked]> writes:

> Make that the required to implement algorithm.

Agreed.

> Also provide for HMAC-SHA-256.  Then we can later (years later) update
> the spec to require HMAC-SHA-256.

Provide for in what way?

Including negotiation of hash algorithm in the mechanism?

Have the hash algorithm be part of the SASL mechanism name and the
GSS-API OID?

Specify that when storing password-equivalents that servers should store
a HMAC-SHA-256 variant for future compatibility?

Thanks,
/Simon

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 28 Mar 2008 02:40:40 +0100

> I propose to use HMAC-SHA-1.  Would you or anyone else object

Yes, for the known reasons, I don't trust that SHA-1/2 is okay.

Unrelated, the PBKDF2 RFC and RMX draft have no examples to
check that implementations actually does what the authors
think it should do.  

 Frank

---

From: [email-masked]
Date: Sat, 29 Mar 2008 20:54:50 -0700 (PDT)

> I propose to use HMAC-SHA-1.  Would you or anyone else object to that?

I think HMAC-SHA-1 makes all kinds of sense.

				Ned