RE: [Hash] Charter discussion, round 1

"Jim Schaad" <ietf@augustcellars.com> Tue, 14 June 2005 22:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiK6u-0003mh-3Q; Tue, 14 Jun 2005 18:42:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiK6s-0003mS-M0 for hash@megatron.ietf.org; Tue, 14 Jun 2005 18:42:18 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14793 for <hash@ietf.org>; Tue, 14 Jun 2005 18:42:15 -0400 (EDT)
Received: from smtp2.pacifier.net ([64.255.237.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKTN-0008IO-DU for hash@ietf.org; Tue, 14 Jun 2005 19:05:38 -0400
Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id A506B830E6 for <hash@ietf.org>; Tue, 14 Jun 2005 15:41:56 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <hash@ietf.org>
Subject: RE: [Hash] Charter discussion, round 1
Date: Tue, 14 Jun 2005 15:43:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcVxMGZiovvAUZbyREu91NZb7i0YkQAATZsA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
In-Reply-To: <p06210210bed50746f518@[10.20.30.249]>
Message-Id: <20050614224156.A506B830E6@smtp2.pacifier.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Content-Transfer-Encoding: 7bit
Cc:
X-BeenThere: hash@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: hash.lists.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hash>
List-Post: <mailto:hash@lists.ietf.org>
List-Help: <mailto:hash-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=subscribe>
Sender: hash-bounces@lists.ietf.org
Errors-To: hash-bounces@lists.ietf.org

Qustions that I have are:


1. Is this new hash function we are considering in phase 1 going to be the
same length as SHA-1 or not?  This would appear to be implied by the goals.
Would replacement of SHA-1 with SHA-256 intact be considered as reasonable
in the first phase?

2. Can we do a reasonable job with phase 1 without having atleast some idea
of what would be required from phase 2, even if it is not a full set of
requirements so that we can evaluate phase 1 againist some type of critera.
Do we then want to start phase 2 (even if it is not completed) right away?

3.  I think that adding explicit deliverables for phase 2 could wait, I
think it must wait until a re-charter for phase 3.

4.  If a new hash function is recommended by this group, will it also be
responible to deal with any new signature algorithms and so forth that come
out of this decision?  For example, DSA is fixed on using SHA-1 and would
need changes to adapt to any new hash algorithm be it a trucated or a seeded
hash algorithm.

jim


-----Original Message-----
From: hash-bounces@lists.ietf.org [mailto:hash-bounces@lists.ietf.org] On
Behalf Of Paul Hoffman
Sent: Tuesday, June 14, 2005 3:16 PM
To: hash@ietf.org
Subject: Re: [Hash] Charter discussion, round 1

[[ 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 <hartmans-ietf@mit.edu>;
      Russ Housley <housley@vigilsec.com>;

Security Area Advisor:
      Russ Housley <housley@vigilsec.com>;

Mailing Lists:
      General Discussion: hash@ietf.org
      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 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
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash


--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Hash mailing list
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash


--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Hash mailing list
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash




_______________________________________________
Hash mailing list
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash