Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04

Sam Hartman <hartmans-ietf@mit.edu> Fri, 28 May 2010 00:33 UTC

Return-Path: <hartmans@mit.edu>
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 95EA23A6916 for <secdir@core3.amsl.com>; Thu, 27 May 2010 17:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.58
X-Spam-Level:
X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334]
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 8PAoHWcYOPDi for <secdir@core3.amsl.com>; Thu, 27 May 2010 17:33:40 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BB3C43A68DE for <secdir@ietf.org>; Thu, 27 May 2010 17:33:40 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3C0A620239; Thu, 27 May 2010 20:33:31 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ACA2E43EF; Thu, 27 May 2010 20:33:00 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: "Bhatia\, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.com>
References: <20100520172310.GQ9605@oracle.com> <tsl632918s3.fsf@mit.edu> <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com>
Date: Thu, 27 May 2010 20:33:00 -0400
In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com> (Manav Bhatia's message of "Fri, 28 May 2010 04:31:55 +0530")
Message-ID: <tsl7hmozwzn.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "vishwas@ipinfusion.com" <vishwas@ipinfusion.com>, "secdir@ietf.org" <secdir@ietf.org>, "shares@nexthop.com" <shares@nexthop.com>, "jjaeggli@checkpoint.com" <jjaeggli@checkpoint.com>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04
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: Fri, 28 May 2010 00:33:41 -0000

>>>>> "Bhatia," == Bhatia, Manav (Manav) <manav.bhatia@alcatel-lucent.com> writes:

    Bhatia,> this - "Attacks on many applications of MD5 are practical
    Bhatia,> on modern computers. For this reason the general use of
    Bhatia,> these algorithms should to be discouraged.[

Right.  I think this text is misleading to the point of being false.
There are attacks against md5 as a hash.  However we have not yet found
a mechanism to turn attacks on md5 as a hash into attacks on hmac-md5 as
a MAC.
It's not a question of the computer power--it's that thes attacks
haven't managed to give an advantage for attacking HMAC.

For other keyed md5 varients more analysis is required, but I would not
at all be surprised if the conclusion were the same: the class of md5
attacks we know about do not apply to md5 in these MAC constructions.

I think the best we can say for discouraging the use of md5 is something
like "There have been attacks against the use of md5 as a hash; while
these attacks do not directly apply to the use of MD5 in routing
protocols, it is prudent to have other options available."

The current text implies that the format of the routing packets, rather
than the format of the MAC construction is what provides protection.
Based on what we've learned about attacking certificates and based on
the fact that all our routing protocols have some extension mechanisms,
I'd find a defense based on the structure of the packets incredibly
weak.