One-way Hash Function BOF (hash)

Monday, August 1 at 1815-1945
=============================

CHAIR: Paul Hoffman <paul.hoffman@vpnc.org>

DESCRIPTION:

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.

AGENDA:

1) Presentations (60 minutes):
   - Ran Canetti on draft-irtf-cfrg-rhash-00.txt
   - Russ Housley on a proposal for message preprocessing
   - Bellovin and Rescorla on IETF protocols and new hashing mechanisms
   - General discussion on tradeoffs of mechanisms and functions

2) Charter discussion (30 minutes);
   - What are the short term and long term objectives for the IETF?
   - Is it possible to set IETF requirements for hash functions?
   - Is a Working Group useful to the IETF? To the outside world?