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
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… George, Wes
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- [sidr] David M's point about the bgpsec protocol … Sandra Murphy
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Keyur Patel (keyupate)
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Montgomery, Douglas
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Randy Bush
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Matthew Lepinski
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- [sidr] Levels of BGPsec/RPKI validation, was: Re:… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… David Mandelberg
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sandra Murphy
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Geoff Huston
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Jared Mauch
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Tim Bruijnzeels
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi