Re: [Hash] Charter discussion, round 1

Paul Hoffman <> Tue, 14 June 2005 22:15 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1DiJhM-0004v4-PY; Tue, 14 Jun 2005 18:15:56 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1DiJhK-0004uz-QC for; Tue, 14 Jun 2005 18:15:54 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id SAA12160 for <>; Tue, 14 Jun 2005 18:15:52 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1DiK3t-0006VZ-UX for; Tue, 14 Jun 2005 18:39:14 -0400
Received: from [] ( []) (authenticated bits=0) by (8.12.11/8.12.9) with ESMTP id j5EMFlib070610 for <>; Tue, 14 Jun 2005 15:15:48 -0700 (PDT) (envelope-from
Mime-Version: 1.0
Message-Id: <p06210210bed50746f518@[]>
In-Reply-To: <p06210245bece4ebbbea1@[]>
References: <> <p06210245bece4ebbbea1@[]>
Date: Tue, 14 Jun 2005 15:15:43 -0700
From: Paul Hoffman <>
Subject: Re: [Hash] Charter discussion, round 1
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

[[ Another nudge, and a re-send for the new people on the list. While 
it would be lovely to think that there are absolutely no issues with 
the suggested charter, IETF history suggests there are probably at 
least a few comments. ]]

Thanks, Russ. So, there are a couple of questions about the charter 
that we can possibly run in parallel:

- Did we leave anything out of phase 1 that would be both useful and 
possible for an IETF Working Group to achieve before we start phase 2?

- Are the milestones for phase 1 reasonable?

- Is the three-phase approach reasonable?

- Do we need to change or add to phases 2 and 3 now, or can we wait 
until the already-scheduled recharter?

For those of you planning on being at the Paris meeting, let's see 
where we get on the charter discussion before we start to set an 
agenda for our face-to-face meeting.

--Paul Hoffman, Director
--VPN Consortium

One-way Hash Function BoF (hash)

Security Area Director:
      Sam Hartman <>;
      Russ Housley <>;

Security Area Advisor:
      Russ Housley <>;

Mailing Lists:
      General Discussion:
      To Subscribe:

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 three-phase approach is envisioned.  The second and third phases will
be pursued only if it is clear that the international cryptographic
community is actively participating in the working group.

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  At least two approaches
will be considered:

   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.  For example, as an alternative to SHA-1, the truncation
      mechanism could be used create a 160-bit result from the output of
      the SHA-256 one-way hash function.

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

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

The second phase 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 third phase will identify one or more standards-track one-way hash
functions that fulfill the requirements stated in the BCP documents
developed in phase two.  Guidance will also be developed to assist
protocol developers in the selection among the standards-track one-way
hash functions.

Goals and Milestones:

September 2005:  Charter to authorize phase one.
October 2005:    Submit initial draft of truncation mechanism.
February 2006:   WG Last Call on truncation mechanism.
April 2006:      Submit truncation mechanism as Proposed Standard.
June 2006:       Recharter to authorize phase two.

Hash mailing list

--Paul Hoffman, Director
--VPN Consortium

Hash mailing list

--Paul Hoffman, Director
--VPN Consortium

Hash mailing list