RE: [Hash] Charter discussion, round 1

Russ Housley <housley@vigilsec.com> Mon, 20 June 2005 14:18 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkN6C-0006LS-Hx; Mon, 20 Jun 2005 10:18:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkN68-0006LC-J9 for hash@megatron.ietf.org; Mon, 20 Jun 2005 10:18:02 -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 KAA02914 for <hash@ietf.org>; Mon, 20 Jun 2005 10:17:58 -0400 (EDT)
Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkNTm-0002Y3-IO for hash@ietf.org; Mon, 20 Jun 2005 10:42:32 -0400
Received: (qmail 30272 invoked by uid 0); 20 Jun 2005 14:17:32 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.170.162) by woodstock.binhost.com with SMTP; 20 Jun 2005 14:17:32 -0000
Message-Id: <6.2.1.2.2.20050620094732.05d64ba0@mail.binhost.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Mon, 20 Jun 2005 10:04:00 -0400
To: "Jim Schaad" <ietf@augustcellars.com>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: [Hash] Charter discussion, round 1
In-Reply-To: <20050617191830.6B39C32735@smtp2.pacifier.net>
References: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com> <20050617191830.6B39C32735@smtp2.pacifier.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: hash@ietf.org
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

Jim:

> > >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?
> >
> > This has already been discussed.  Below I propose some words
> > in the charter to capture the discussion.
>
>Do we have any research available to use about the strengths of truncated
>hashes?

As we have already seen posted here, this is the approach being used in 
ECDSA.  Also, NIST is working on a document in this area.  I hope that John 
Kelsey will finish the document before the -00 cutoff, but that seem 
unlikely at this point.

> > >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?
> >
> > I do not think so.  I think we understand the needs for
> > signatures, which is the primary issue for phase 1.
>
>In my understanding of the world, it is in the case of signatures that the
>requirements placed on hash functions are the most restrictive.  If we
>understand this set of needs then phase 2 is just a case of identifying the
>other places where hash functions are used and figuring out which of the
>signature elements still apply.
>
>Other places that hash functions are used (not all cases are applicable to
>the IETF and list is not complete) -
>         - collision resistance - i.e. building a symbol table based on the
>hash of a symbol
>         - low level integrity check - assumes the absence of an attacker
>         - keyed hash function authentication

I do not see any disagreement here ...

> > >3.  I think that adding explicit deliverables for phase 2 could wait, I
> > >think it must wait until a re-charter for phase 3.
> >
> > Are you saying that we can do a good job on Phase 2 even if
> > the participation from the international crypto community is low?
>
>Yes I think so, we are identifying the locations where hash functions are
>being used or are likely to be used in IETF protocols.  We are then
>specifying what prosperities are needed in these situations.  This does not
>seem to be highly reliant on big research issues.

I would like to see more discussion of this point on this mail list and ant 
the BoF.  You might be able to convince me that we should include Phase 1 
and Phase 2 in the first version if the charter.

> > >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.
> >
> > If you are talking about the assignment of algorithm
> > identifiers, I am not really concerned about who does it.
> >
> > A new hash function should not have deep ripples into the
> > signature algorithms.  It may have an impact on protocols to
> > carry parameters.
>
>If we propose to replace SHA-1 in DSA/ECDSA then there is a big change for
>those signature algorithms.
>If we propose to replace SHA-1 for RSA v1.5 - that might be a big change,
>but I would say we should just jump to RSA-PSS where this is not a big
>issue.
>I agree it might have a huge impact on some protocols as well.

I believe that the complexity should be less than adding support for a new 
hash/signature pair.  This should be fairly straightforward if the 
implementation has any kind of a crypto API.  The biggest ripple would seem 
to be looking into the algorithm identifier parameters.  Previously, these 
were always absent or NULL, so a new bit of code will be needed here.

Russ


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