[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: WG Last Call: SHA-224


At 4:35 PM -0500 3/30/04, Alice Sturgeon wrote: 
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.

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

TripleDES is neither passé nor obsolete in the IETF. New security standards such as IKEv2 from the IPsec WG are mandating 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.

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.

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.

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.

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.

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.

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.

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.

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.

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

--Paul Hoffman, Director
--Internet Mail Consortium