Subject: WG Last Call: SHA-224

From: Tim Polk <[email-masked]>
Date: Fri, 26 Mar 2004 16:14:34 -0500

Folks,

This message initiates working group last call for "A 224-bit One-way Hash 
Function: SHA-224"  This document is currently available at 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-00.txt.  The 
author has suggested Informational Track for this document, so last call 
will be one week.  That is, Last Call for this document closes on or after 
April 2, 2004.

This specification will provide a stable reference for the SHA-224 
algorithm, which is needed by several IETF specifications.  At least two 
independent implementations exist and agree on the test vectors in this 
document.

Thanks,

Tim Polk

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 28 Mar 2004 10:52:58 -0800

At 4:14 PM -0500 3/26/04, Tim Polk wrote:
>algorithm, which is needed by several IETF specifications.

In searching the Internet Drafts directory, only four documents even 
mention SHA-224:

eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a requirement

pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement

pkix-sha224: the document in question

smime-cms-rsa-kem: uses it but does not justify why it needs it 
instead of SHA-256

The train may have left the station on this one, but it is really 
pretty silly. The only possible use is in severely 
bandwidth-restricted environments where an extra 32 bytes is 
important. None of the documents above discuss any such environments.

It is silly to say that SHA-256 doesn't "match" 112 bits of 
encryption strength. There is no disadvantage to having more bits of 
randomness, particularly because TripleDES doesn't use 112-bit blocks.

This document would be well-served to have an additional paragraph 
explaining that systems that use TripleDES and need a matching hash 
algorithm SHOULD use SHA-256, not SHA-224, unless they are in 
severely bandwidth-restricted environments.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Mar 2004 08:21:10 -0500

Paul:

I understand that the computation expense is the same as SHA-256.  However, 
as you point out, there are times that a shorter hash value is desirable.

I would be willing to add a paragraph to the security considerations that 
point out the equal computational cost for SHA-256 if that would make you 
feel better.

Russ

At 10:52 AM 3/28/2004 -0800, Paul Hoffman / IMC wrote:

>smime-cms-rsa-kem: uses it but does not justify why it needs it instead of 
>SHA-256
>
>The train may have left the station on this one, but it is really pretty 
>silly. The only possible use is in severely bandwidth-restricted 
>environments where an extra 32 bytes is important. None of the documents 
>above discuss any such environments.
>
>It is silly to say that SHA-256 doesn't "match" 112 bits of encryption 
>strength. There is no disadvantage to having more bits of randomness, 
>particularly because TripleDES doesn't use 112-bit blocks.
>
>algorithm SHOULD use SHA-256, not SHA-224, unless they are in severely 
>bandwidth-restricted environments.
>
>--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Mar 2004 06:44:51 -0800

At 8:21 AM -0500 3/29/04, Russ Housley wrote:
>I understand that the computation expense is the same as SHA-256. 
>However, as you point out, there are times that a shorter hash value 
>is desirable.

Do we agree that the only times where it is desirable is in severely 
bandwidth-restricted environments? Or am I missing some other 
scenario?

>I would be willing to add a paragraph to the security considerations 
>that point out the equal computational cost for SHA-256 if that 
>would make you feel better.

That's not necessary, and it isn't really a security consideration. 
My preference would be that the document include advice to protocol 
designers about when this is and is not a useful algorithm; without 
that, designers might think they understand its usefulness when they 

--Paul Hoffman, Director

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Mar 2004 10:25:57 -0500

Paul:

>>However, as you point out, there are times that a shorter hash value is 
>>desirable.
>
>bandwidth-restricted environments? Or am I missing some other scenario?

It is also useful is you want all of the algorithms in a cipher suite to 
offer the same strength.  I remember a SAAG discussion that this was called 
"impedance match," but I do not particularly like that term.

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Mar 2004 07:41:41 -0800

At 10:25 AM -0500 3/29/04, Russ Housley wrote:
>>>However, as you point out, there are times that a shorter hash 
>>>value is desirable.
>>
>>Do we agree that the only times where it is desirable is in 
>>severely bandwidth-restricted environments? Or am I missing some 
>>other scenario?
>
>It is also useful is you want all of the algorithms in a cipher 
>suite to offer the same strength.  I remember a SAAG discussion that 
>this was called "impedance match," but I do not particularly like 
>that term.

This is all the more reason to put material in the document that 
tells protocol designers what the design goals for SHA-224 are. Such 
wording should explicitly say that SHA-224 SHOULD NOT be used with 
AES-128 or other asymmetric ciphers that have greater than 112 bits 
of strength.

The reason I am hammering on this is that it is somewhat absurd to 
purposely reduce the strength of one of the algorithms in a cipher 
suite just so it "matches". For example, assume that someone this 
year discovers a trivial method for reducing the effective strength 
of TripleDES from 112 to 108 bits. Clearly, no one is going to stop 
using TripleDES or a suite that uses TripleDES. But, using the logic 
that prompted the creation of SHA-224, we will need a new RFC that 
specifies SHA-216 by shaving off eight more bits from the SHA-256 
result.

Instead of this progression, we should be giving protocol designers 
advice that says "it is fine to use a hash algorithm that produces 
more bits than are needed to 'match' the symmetric key strength".

--Paul Hoffman, Director

---

From: "Alice Sturgeon" <[email-masked]>
Date: Tue, 30 Mar 2004 16:35:59 -0500

Hi Paul, Tim, Russ et al.,

My colleague Bob Jueneman and I have been following this thread with great
interest and some concern, the latter already reflected in the thread,
Paul's post below and some of today's more recent ones.

We agree with Paul's views generally on this subject, in terms of the
usefulness of SHA-224 and the potential impact of its standardization.

We are strongly opposed to standardizing SHA-224, and at present have no
plans to implement it even if it does become a standard.  It seems highly
unlikely that 32 bits would make a substantial difference, even in a
restricted bandwidth environment.  And because the SHA-224 is simply a
truncation of SHA-256, it certainly isn't saving any time.  Its sole purpose
seems to be to fine-tune an "impedance match" with a triple-DES key, when
triple-DES itself is effectively passe and obsolete, notwithstanding the
fact that many applications still use it.

Standardization groups need to remember that there is a cost, often
considerable, to adding features that someone thinks are needed (or simply
that someone thinks are cool), and that, at the end of the day, are not used
in sufficient volume to warrant these costs, of standardization, enabling
interoperability among all the parts.

It sometimes seems that, when an RFP comes up for bid, the race is on to see
who can offer the most features and is compliant with the many standards
that are referenced.  Unfortunately, in a lot of cases neither the RFP
preparers nor the award committee are experts on the fine points of the
standards, and so they simply look at the list of standards and apply a
check-box score to the results.

This inevitably leads to more and more bloated code, more and more potential
errors, and hence more opportunities for security flaws, etc. And in the
case of SHA-224 all of this is done to save 32 bytes, which a protocol
designer could do themselves if they thought it was really, really
important.

But in addition to the problem of bloated code, there is a much more serious
issue of interoperability testing, because for every new "feature" of this
type there is a combinatoric* explosion of interfaces to be tested.  That in
turn drives up the cost of the product, and inescapably drives down the
quality, for there are never sufficient testing resources to go around.

That's why we oppose the standardization of SHA-224, or the use of it in any
IETF protocols, including the ANSI X9.82 Random Number Generation standard
currently being developed.

Having gone this far, we might also question the need for AES-192, SHA-384,
or the corresponding strength elliptic curves as well.  From the timing data
that we've seen, none offers any great savings in time, and in our view the
differences in space are hardly worth it.

As Paul says, these trains may have already left the station but just to let
you know that we jumped off.

(*  Word thinks that "combinatoric" is not a word.  But Google thinks that
it is, and informs you that you can buy one on eBay! :) )

Alice Sturgeon

System Policy Architect
SPYRUS

Chair, Canadian Advisory Committee - IT Security
ISO/IEC JTC 1/SC 27

Phone:  613-232-2350
Cell:  613-291-0331

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Paul Hoffman / IMC
Sent: Sunday, March 28, 2004 1:53 PM
To: Tim Polk; [email-masked]
Subject: Re: WG Last Call: SHA-224

eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a
requirement

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Mar 2004 14:14:47 -0800

>usefulness of SHA-224 and the potential impact of its standardization.

Errr, that's not what I said. The last call for this document 
explicitly said that it is expected to be an Informational RFC. 
Informational RFCs have absolutely no standards values. I see no 
problem with the publication of this document as an Informational RFC 
as long as it contains guidance to protocol developers.

>Its sole purpose

TripleDES is neither passé nor obsolete in the IETF. New security 
standards such as IKEv2 from the IPsec WG are mandating it.

>interoperability among all the parts.

Fully agree. However, the likelihood that someone will misunderstand 
how to truncate a value, particularly when the specification document 
has multiple easy-to-read test vectors, is quite low.

>designer could do themselves if they thought it was really, really

At least I'm not the only one who says "32 bytes" when the actual 
amount is "32 bits". :-) And, no, we don't want protocol designers to 
do it themselves, given that protocols often interact. That's why we 
have Informational RFCs that describe algorithms such as this.

>quality, for there are never sufficient testing resources to go around.

A hash function has one input and one output. Testing it is rather 
easy, particularly compared to functions with multiple inputs, 
multiple outputs, or structured inputs and/or outputs. And, again, 
this document has worked-out test vectors.

>currently being developed.

If you are worried about it being standardized in the IETF, don't be: 
it is meant to be an Informational RFC. If you want to prevent its 
use in any IETF protocol, you need to send that message to the WGs 
working on those protocols. For grins, you might send messages to WGs 
that are working on protocols mandating TripleDES and tell them that 
TripleDES is passé and obsolete.

>differences in space are hardly worth it.

See previous comment. You might as well start all the flame wars at once.

--Paul Hoffman, Director