Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"

"David McGrew (mcgrew)" <mcgrew@cisco.com> Wed, 28 November 2012 15:23 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808D521F8843 for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 07:23:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQAaIrjoJzUP for <saag@ietfa.amsl.com>; Wed, 28 Nov 2012 07:23:07 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0F7321F8801 for <saag@ietf.org>; Wed, 28 Nov 2012 07:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1472; q=dns/txt; s=iport; t=1354116187; x=1355325787; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Da/w+X8tWhlMjmUtLtNZS1Ac0KreKOglNAJFjGdptHY=; b=ansSb223+zgwt0FgXHD2xKen444XUm4/cZ0ghw+AISxWDH8ttLzA2/0o bf2kwB6IidUjmrqngxfW020NS8VP88QumbyIKgQMq6Rz0hwuJjsUfC8mA Wr5RQbcrakSIAFxlG/KeHQfjZ4g3aHU6bSTF2SU83NP4PGoXB/iN4Wl2l 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANgrtlCtJXG9/2dsb2JhbABFwBUWc4IgAQQ6PxIBCCIUQiUCBA4NiAe/AZAfYQOmRYJwgiE
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="147155358"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 28 Nov 2012 15:23:07 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qASFN6oc023451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 15:23:06 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 09:23:06 -0600
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
Thread-Index: AQHNweyKBFECjqGD4EK+xvmKz2CDQJfpYOIAgADxLoCAFTNfAA==
Date: Wed, 28 Nov 2012 15:23:06 +0000
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F54B22B@xmb-rcd-x04.cisco.com>
In-Reply-To: <AEAA7B57-4523-4E19-953B-DD06504A4785@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.117.10.227]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A3A6A21F371A914291BE0E89F1D0444E@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 15:23:08 -0000

Hi Paul,

A quick comment.   The draft says that uses for hash algorithms include

   o  Integrity protection.  It is common to compare a hash value that
      is received out-of-band for a file with the hash value of the file
      after it is received over an unsecured protocol such as FTP.

... and it then says that collision resistance is not needed for the
integrity protection use case.   However, it seems to me that there are
possible threats against hash-based integrity protection that would be
possible if the person/system generating the hash can generate collisions,
and is untrustworthy.  Consider the case of an md5sum hash on a debian ISO
image.  If the person responsible for generating the hash can create a
malware-laden ISO imagine that has a hash collision with the actual ISO
image, then they could substitute the bad one for the good one regardless
of the hash checking step.  An attacker might leave the good ISO image in
place to avoid detection, while foisting the bad one on some victims.  I
am assuming that there are different ways of distributing ISO images, or
that the substitution of bad for good can take place after the good one
has been investigated and found to be good.

It is debatable how important this scenario is in practice, but it seems
that collision resistance is at least desirable for integrity protection.

David

P.S. - apologies for picking on debian, which is a most excellent distro
:-)