[Hash] Charter discussion, round 2

[Paul Hoffman <[e-mail]>]

Greetings again. Thank you to everyone who helped with the first 
round. My take is that people don't see much need to segregate the 
truncation/salting discussion from the meatier requirements 
discussion. Also, looking at the mailing list, we are already seeing 
a reasonable level of subscription from some well-known names in the 
cryptography community.

Given that, I would like to propose a similar-but-different charter 
that gets us started on the more significant issues earlier. Please 
comment on the list whether you think the text is or is not 
reasonable, the goals are or are not achievable, and the timeline is 
or is not sensible.

--Paul Hoffman, Director
--VPN Consortium


One-way Hash Function BoF (hash)

Security Area Director:
      Sam Hartman <[e-mail]>
      Russ Housley <[e-mail]>

Security Area Advisor:
      Russ Housley <[e-mail]>

Mailing Lists:
      General Discussion: [e-mail]
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
      Archive:            http://www.ietf.org/mail-archive/web/hash/index.html

Description of Proposed Working Group:

Recently, a team of researchers reported that the SHA-1 one-way hash
function offers significantly less collision resistance than could be
expected from a cryptographic hash function with an output of 160 bits.
This result has inspired significant research activities in government
and academia.  Additional information regarding the security of current
one-way hash functions, as well as proposals for new one-way hash
functions, are expected.  The proposed working group responds to the
current state of research in this area.  However, additional research is
likely to provide new insights as the working group progresses.

A two-phase approach is envisioned.  The second phase will be pursued by
revising the charter, only after the first phase is finished and if it
is clear that the international cryptographic community is actively
participating in the working group.

The first phase will consist of two main areas of work: setting
requirements for the use of one-way hash functions in IETF protocols,
and describing ways to make current hash functions more robust. These
two work items can be done in parallel.

The working group will consider the suitability of one-way hash
functions for use with IETF protocols.  These requirements will be
published as one or more BCP documents which specify the features and
characteristics for standards-track one-way hash functions.  The BCP
documents will also identify information that must be included in any
request for a hash function to be approved on the standards track.

The DSA signature algorithm requires a hash function whose output is 160
bits.  The working group will consider at least two approaches to
strengthen one-way hash functions for use in DSA:

   1) Truncate a larger one-way hash function output so that it can be
      used as a secure replacement of a shorter one-way hash function
      output.

   2) Including a random value in the hash function computation. The
      random block used is transferred as a field in the algorithm
      identifier data structure.  This approach is sometimes called a
      "salted" or "randomized" hash function.

The working group may also consider other potential solutions, and one
or more standards-track mechanism will be selected.

The optional second phase will identify one or more standards-track
one-way hash functions that fulfill the requirements stated in the BCP
documents developed in the first phase.  Guidance will also be developed
to assist protocol developers in the selection among the standards-track
one-way hash functions.

Goals and Milestones:

August 2005:     Charter working group to authorize first phase.
September 2005:  Submit initial draft of truncation mechanism and/or
                    salting mechanism.
November 2005:   Submit initial drafts on hash requirements,
                    descriptions, and suitability.
February 2006:   WG Last Call on truncation mechanism and/or salting
                    mechanism.
March 2006:      Submit truncation mechanism and/or salting mechanism
                    for IETF standard.
August 2006:     Begin WG Last Calls on hash requirements, descriptions,
                    and suitability.
June 2007:       Submit hash requirements, descriptions, and suitability
                    documents for BCP.
June 2007:       Recharter working group to authorize second phase.

_______________________________________________
Hash mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hash