Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

Michael Baer <baerm@tislabs.com> Wed, 11 February 2015 06:17 UTC

Return-Path: <baerm@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B656E1A6FEE for <sidr@ietfa.amsl.com>; Tue, 10 Feb 2015 22:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LA07bypRFrT for <sidr@ietfa.amsl.com>; Tue, 10 Feb 2015 22:17:14 -0800 (PST)
Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id EBCBB1A0024 for <sidr@ietf.org>; Tue, 10 Feb 2015 22:17:13 -0800 (PST)
Received: from localhost (unknown [IPv6:2001:470:1f05:274:3e97:eff:feba:52f]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 9BDB8395D3E; Tue, 10 Feb 2015 22:17:13 -0800 (PST)
From: Michael Baer <baerm@tislabs.com>
To: David Mandelberg <david@mandelberg.org>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org>
X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.:<GckOP:; wBMTb7\%Y"JI=R<M6g?6}tR)6Z7rp5X*24G\bkb!
Date: Tue, 10 Feb 2015 22:17:13 -0800
In-Reply-To: <54DA7C98.4040604@mandelberg.org> (David Mandelberg's message of "Tue, 10 Feb 2015 16:48:08 -0500")
Message-ID: <87k2zpdlau.fsf@rebma.mikesoffice.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/VzL8G9eiEepj4OIq8Gcw2RTd69c>
Cc: sidr@ietf.org
Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 06:17:15 -0000

>>>>> On Tue, 10 Feb 2015 16:48:08 -0500, David Mandelberg <david@mandelberg.org> said:

    DM> All, while coming up with the example below, I realized another
    DM> issue.  The structure in 4.1 doesn't include an Address Family
    DM> Identifier.  Unless I missed something, this means that a
    DM> signature for 1.2.0.0/16 would be exactly the same as a
    DM> signature for 102::/16. This would be a much more practical
    DM> attack than the one I originally though of.

    DM> Michael, response to your comment is below.

    DM> On 02/10/2015 12:09 PM, Michael Baer wrote:
    >> I don't believe this is a problem.  The signature is calculated
    >> by creating a digest of the data and then creating a signature
    >> from that digest.  I'm definitely not a cryptography expert, but
    >> my understanding of digest functions generally is that with even
    >> slightly differing input, the resulting set of bits should be
    >> completely different.  Assuming the digest function chosen is not
    >> flawed, there shouldn't be a set of bits from the digest of 4.1
    >> that could be used to successfully replace the digest of 4.2,
    >> except by chance.

    DM> You're right about digest algorithms being highly sensitive to
    DM> changes in the input, but the issue I described is when the two
    DM> inputs are equal, not just similar. For example, if a router
    DM> signed the below values in the structure from 4.2:

    DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708
    DM> pCount = 0x01 Flags = 0x00 Most Recent Sig Field =
    DM> 0x00700102030405060708090a0b0c0d0e (See Sriram's email for why
    DM> this would never actually happen with the current algorithm
    DM> suite's signature length.)

Ah, I see. Thanks for the explanation.  I was not understanding the
attack vector but I get how it would work now (and good to know the
input won't match with the current algorithm).

-Mike


    DM> Then the router signed the digest of the bytes
    DM> 0x0102030405060708010000700102030405060708090a0b0c0d0e. However,
    DM> these exact same bytes could appear to have come from the
    DM> structure in 4.1 with these values:

    DM> Target AS Number = 0x01020304 Origin AS Number = 0x05060708
    DM> pCount = 0x01 Flags = 0x00 Algorithm Suite Id = 0x00 NLRI Length
    DM> = 0x70 (112 bits = 14 bytes) NLRI Prefix =
    DM> 0x0102030405060708090a0b0c0d0e

    DM> Note that the first 16 bits of 4.2's Most Recent Sig Field can't
    DM> be any values. The first 8 have to match the Algorithm Suite ID
    DM> (1 possible value). The next 8 have to be a valid number of bits
    DM> for the number of bytes in the prefix (8 possible values). This
    DM> means that there's only a 2^-13 chance that a single random Most
    DM> Recent Sig Field of the appropriate length could be
    DM> reinterpreted successfully. However, with more than 2^13
    DM> signatures floating around the Internet, that's not good odds.

    DM> -- David Eric Mandelberg / dseomn http://david.mandelberg.org/


    DM> _______________________________________________ sidr mailing
    DM> list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr

-- 
Michael Baer
baerm@tislabs.com