IETF Logo Mail Archive

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

Sam Hartman <hartmans-ietf@mit.edu> Fri, 28 May 2010 00:27 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 6F2673A69D8 for <secdir@core3.amsl.com>; Thu, 27 May 2010 17:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, 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 ys+4bj2TbS84 for <secdir@core3.amsl.com>; Thu, 27 May 2010 17:26:58 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A8BE3A699F for <secdir@ietf.org>; Thu, 27 May 2010 17:25:08 -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 3BEA320239; Thu, 27 May 2010 20:23:57 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B284A43EF; Thu, 27 May 2010 20:23:26 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Sandra Murphy <Sandra.Murphy@sparta.com>
References: <20100520172310.GQ9605@oracle.com> <tsl632918s3.fsf@mit.edu> <Pine.WNT.4.64.1005271452060.2996@SMURPHY-LT.columbia.ads.sparta.com>
Date: Thu, 27 May 2010 20:23:26 -0400
In-Reply-To: <Pine.WNT.4.64.1005271452060.2996@SMURPHY-LT.columbia.ads.sparta.com> (Sandra Murphy's message of "Thu, 27 May 2010 14:56:26 -0400 (Eastern Daylight Time)")
Message-ID: <tslfx1czxfl.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: manav.bhatia@alcatel-lucent.com, vishwas@ipinfusion.com, secdir@ietf.org, shares@nexthop.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:27:16 -0000

>>>>> "Sandra" == Sandra Murphy <Sandra.Murphy@sparta.com> writes:

    Sandra> I was discussing this just this morning with a colleague.
    Sandra> The discussion of pre-image and collision points out that
    Sandra> using collisions as an attack on a routing protocol is not
    Sandra> that easy since routing protocols have format requirements -
    Sandra> the attacker would have to find a collision that is also a
    Sandra> validly formatted protocol packet.

I actually find this argument uncompelling.  Certificates have format
requirements, but we've generally found that extensible data structures
typically have space somewhere for the bits that you need to make an
attack possible.

What's more interesting to me is the affect of the key on the ability to
prepare for such an attack.

v2.8.10 | Report a Bug | By Email