[secdir] SecDir review of draft-ietf-csi-hash-threat-09

"Laganier, Julien" <julienl@qualcomm.com> Wed, 10 March 2010 17:23 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E523A6C0A; Wed, 10 Mar 2010 09:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.389
X-Spam-Level:
X-Spam-Status: No, score=-105.389 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkgq6jukeW56; Wed, 10 Mar 2010 09:23:53 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6864A3A6C0B; Wed, 10 Mar 2010 09:23:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1268241817; x=1299777817; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"secdir@ietf.org"=20<secdir@ietf.org>,=0D=0A=09"dr aft-ietf-csi-hash-threat@tools.ietf.org"=0D=0A=09<draft-i etf-csi-hash-threat@tools.ietf.org>,=20"iesg@ietf.org"=20 <iesg@ietf.org>,=0D=0A=09"csi-chairs@tools.ietf.org"=20<c si-chairs@tools.ietf.org>|Date:=20Wed,=2010=20Mar=202010 =2009:23:09=20-0800|Subject:=20SecDir=20review=20of=20dra ft-ietf-csi-hash-threat-09|Thread-Topic:=20SecDir=20revie w=20of=20draft-ietf-csi-hash-threat-09|Thread-Index:=20Ac rAdlr+WT9n88UoThCYk7RVGpFEAg=3D=3D|Message-ID:=20<BF345F6 3074F8040B58C00A186FCA57F1C6A8C4581@NALASEXMB04.na.qualco mm.com>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=RjcyAHx/tSi+Pn3rcjWYU+1T082rxhD30klB03bmq4g=; b=AJCyGf/fGSqAXRri67VxuOvbJK4CwWMO5Bf2lFBI/v/vRK5I14JFguuR HPVi+v9lRLFhCT6xP+fcQdjnLgNA1xBmUfjP3t4WxRaiBi+JXfYmd6UjT 8hLoiMTuV1jciPVIJ/AWhAJrC1Lup1BDXFC//A/KJxaf+ct2T1WhUYVHu w=;
X-IronPort-AV: E=McAfee;i="5400,1158,5916"; a="36050649"
Received: from ironstorm.qualcomm.com ([172.30.39.153]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2010 09:23:35 -0800
X-IronPort-AV: E=Sophos;i="4.49,614,1262592000"; d="scan'208";a="51612147"
Received: from unknown (HELO nasanexhub02.na.qualcomm.com) ([10.46.143.120]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Mar 2010 09:23:34 -0800
Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 10 Mar 2010 09:23:12 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 10 Mar 2010 09:23:12 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-csi-hash-threat@tools.ietf.org" <draft-ietf-csi-hash-threat@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "csi-chairs@tools.ietf.org" <csi-chairs@tools.ietf.org>
Date: Wed, 10 Mar 2010 09:23:09 -0800
Thread-Topic: SecDir review of draft-ietf-csi-hash-threat-09
Thread-Index: AcrAdlr+WT9n88UoThCYk7RVGpFEAg==
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C6A8C4581@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir review of draft-ietf-csi-hash-threat-09
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: Wed, 10 Mar 2010 17:23:54 -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 last call comments.

Document Abstract:

   This document analysis the use of hashes in SEND, possible threats
   and the impact of recent attacks on hash functions used by SEND.
   Current SEND specification [rfc3971] uses the SHA-1 [sha-1] hash
   algorithm and X.509 certificates [rfc5280] and does not provide
   support for the hash algorithm agility.  The purpose of the document
   is to provide analysis of possible hash threats and to decide how to
   encode the hash agility support in SEND.

Summary: Most of the document tries to explains how an attack on a given property of a hash function does or does not translate into an attack on other hash-based cryptographic primitives (signature, certificate.) IMHO This document is not the right place to do so (these are documented elsewhere.) Moreover, the document fail to clearly articulate how attacks against these hash-based cryptographic primitives translates or does not translate into attacks against the SEND protocol itself. Thus I think the document in its current form is not ready for publication and requires more work.

Detailed comments: 

- Section 3 explains what is a first-preimage attack, a second preimage attack, a collision attacks, etc. I do no think this document is the right place to do this. A simple reference to the definition of the attacks could be added if necessary, e.g. "For a definition of the various attacks against hash function properties, see [HAC] [...] [HAC] Handbook of Applied Cryptography, Alfred J. Menezes et al., 2001, http://www.cacr.math.uwaterloo.ca/hac/"

- Section 3.1. explains that the "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982]", yet it goes on with explaining what is the purpose of a CGA etc. If RFC4982 has done the analysis already, simply cite it, and state the result, e.g. "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982] which concludes that no current hash vulnerability impacts the security properties afforded by the use of CGAs".

- Section 3.2 similarly goes on musing on attacks against X.509 certificates. Again, I'd rather have the section refer to an analysis of the vulnerabilities introduced by the use of hashes by X.509 certificates, and simply state the conclusion of the analysis in this document. If no proper analysis has been done, then it could be done in this document, but this section as is doesn't seem to do that in an appropriate way.

- Section 3.3. has a similar problem as above. It muses on non-repudiation etc. but does not say what I'm interested in. If security of SEND does not rely on non-repudiation property of the signature, state it and explain why. I am not interested in how to attack the non-repudiation property of a signature using a hash vulnerability, I am interested in how can (or can't) I attack SEND using a non-repudiation vulnerability...

Editorial: the use of the English language could be improved.

--julien