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

Suresh Krishnan <> Thu, 11 March 2010 05:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 325E93A6ABB; Wed, 10 Mar 2010 21:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MCgHLK9GA21F; Wed, 10 Mar 2010 21:29:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E25DB3A6816; Wed, 10 Mar 2010 21:29:49 -0800 (PST)
Received: from ([]) by (8.13.1/8.13.1) with ESMTP id o2B5Wfmv023207; Wed, 10 Mar 2010 23:32:41 -0600
Received: from [] ( by ( with Microsoft SMTP Server id 8.1.375.2; Thu, 11 Mar 2010 00:29:53 -0500
Message-ID: <>
Date: Thu, 11 Mar 2010 00:25:33 -0500
From: Suresh Krishnan <>
User-Agent: Thunderbird (X11/20090817)
MIME-Version: 1.0
To: Paul Hoffman <>
References: <> <p06240804c7bd964b880f@[]>
In-Reply-To: <p06240804c7bd964b880f@[]>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] SecDir review of draft-ietf-csi-hash-threat-09
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Mar 2010 05:29:51 -0000

Hi Julien/Paul,
    I agree with the points you have made regarding the gratuitous
(and sometimes overreaching) text. That said, I think there is value in
continuing with the document. The document needs to still talk about the 
following threats to SEND

* Threats due to the hash algorithm used for the SEND router certificates.
* Threats due to the hash algorithm used for the digital signature in 
the RSA signature option used in SEND.
* Threats due to the hash algorithm used for the creating the hash of 
the public key in the RSA signature option.

There is no other document that talks about these threats and how likely 
they are to occur in practice. We will make another editorial pass to 
remove test that is duplicated from the references and clean out some 
excessive text.


On 10-03-10 01:54 PM, Paul Hoffman wrote:
> At 9:23 AM -0800 3/10/10, Laganier, Julien wrote:
>> - 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,"
> Or just shorten it to a two-sentence reference to RFC 4270, which is repeatedly referred to in this section.
>> - 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".
> Quite right.
>> - 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.
> Fully agree. The quality of collision-based attacks on PKIX certificates continues to improve every few years. Arjen Lenstra and Benne de Weger have no problem finding grad students (and even undergraduates) who want to make their name in this area, often with success.
>> - 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...
> Non-repudiation is one of the best-known ratholes in the PKIX space.
> I apologize for not reading this document sooner, but it is really a mess and should not be published even as an Informational RFC. In addition to the problems listed above, the document is also riddled with factual problems:
> - It says that it "analyzes the hash usage in SEND following the recommended approach [rfc4270] [new-hashes]" but does not deal with the methods in [new-hashes] (which has an under-specified reference) at all.
> - It says that RFC 4270 says many things that absolutely are not in RFC 4270.
> - It says that there have been SHA-1 collisions, which are still likely but still completely theoretical.
> - There are numerous context-free statements like "The strength of Internet protocol does not have to be necessarily affected by the weakness of the underlaying hash function".
> - The CGA-specific discussion of if preimage attacks were feasible ignores the fact that CGA is the least of anyone's worries if preimage attacks were feasible: there would be a systemwide security meltdown, of which CGA would be a tiny whiff.
> Please strongly consider killing off this document, given that RFCs 4270 and 4982 already cover the material completely. If RFC 4982 does not cover every aspect relevant to SEND, a two-paragraph update to RC 4982 would be much better than this document.