[secdir] Secdir review of draft-schaad-smime-hash-experiment-03

Brian Weis <bew@cisco.com> Mon, 20 December 2010 19:22 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6DA843A6AA6; Mon, 20 Dec 2010 11:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id RL-8WgxPShKN; Mon, 20 Dec 2010 11:22:17 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id 309AC3A6AA2; Mon, 20 Dec 2010 11:22:17 -0800 (PST)
Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKc7D02rR7Hu/2dsb2JhbACkGXOjUps6hUkEhGWGHA
X-IronPort-AV: E=Sophos;i="4.60,203,1291593600"; d="scan'208";a="252983964"
Received: from sj-core-5.cisco.com ([]) by sj-iport-3.cisco.com with ESMTP; 20 Dec 2010 19:24:11 +0000
Received: from dhcp-128-107-147-31.cisco.com (dhcp-128-107-147-31.cisco.com []) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBKJOB0S010309; Mon, 20 Dec 2010 19:24:11 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Dec 2010 11:24:13 -0800
Message-Id: <2B08467E-1263-4B0B-9B9D-0A17762015F8@cisco.com>
To: secdir@ietf.org, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Cc: draft-schaad-smime-hash-experiment@tools.ietf.org
Subject: [secdir] Secdir review of draft-schaad-smime-hash-experiment-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Dec 2010 19:22:18 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the  IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other review comments.

This document proposes an experiment to detect if there are major problems in using hash algorithms that include parameters as part of CMS and S/MIME. To that end, it defines a weak un-keyed hash algorithm that includes a parameter, and also the ASN.1 definition needed to passed the parameter within the CMS data structure.

Both the hash definition and Security Considerations section make it clear that the defined hash is not expected to provide a sufficient level of security, and is not intended for use outside of the experiment. However, I just wonder if that is a reasonable expectation; Experimental RFCs do get implemented. Even the presence of the statement "This hash function MUST NOT be released as shipping code, it is designed only for use in experimentation." in Section 1 may not be enough to stop implementation of what might look to naive readers as an interesting new hash function appeared to be published "by the IETF".

It might be helpful to follow this MUST NOT statement with one or more references to parameterized hash functions that have been published for a security review and might be good actual candidates in the future. I am not an expert in this area, but one that seems to fit this criteria is: Shai Halevi, et. al, "Implementing the Halevi-Krawczyk Randomized Hashing Scheme",  <http://webee.technion.ac.il/~hugo/rhash/implementation.pdf>.

Other than one suggestion, I do not see the need for any changes.