Skip to main content

Last Call Review of draft-schaad-smime-hash-experiment-

Request Review of draft-schaad-smime-hash-experiment
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-01-18
Requested 2010-12-16
Authors Jim Schaad
I-D last updated 2011-01-04
Completed reviews Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-schaad-smime-hash-experiment by Security Area Directorate Assigned
Completed 2011-01-04
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the  IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
review comments.

This document proposes an experiment to detect if there are major problems in
using hash algorithms that include parameters as part of CMS and S/MIME. To
that end, it defines a weak un-keyed hash algorithm that includes a parameter,
and also the ASN.1 definition needed to passed the parameter within the CMS
data structure.

Both the hash definition and Security Considerations section make it clear that
the defined hash is not expected to provide a sufficient level of security, and
is not intended for use outside of the experiment. However, I just wonder if
that is a reasonable expectation; Experimental RFCs do get implemented. Even
the presence of the statement "This hash function MUST NOT be released as
shipping code, it is designed only for use in experimentation." in Section 1
may not be enough to stop implementation of what might look to naive readers as
an interesting new hash function appeared to be published "by the IETF".

It might be helpful to follow this MUST NOT statement with one or more
references to parameterized hash functions that have been published for a
security review and might be good actual candidates in the future. I am not an
expert in this area, but one that seems to fit this criteria is: Shai Halevi,
et. al, "Implementing the Halevi-Krawczyk Randomized Hashing Scheme",  <


Other than one suggestion, I do not see the need for any changes.