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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

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

ned+ietf-sasl@xxxxxxxxxxx writes:

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