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

David Mandelberg <> Tue, 10 February 2015 21:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 04BAA1A86F7 for <>; Tue, 10 Feb 2015 13:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tvPqHB7uya1i for <>; Tue, 10 Feb 2015 13:48:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AFC31A19FA for <>; Tue, 10 Feb 2015 13:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1423604880; bh=/MiVZk5T1y4r+tDdGA3LtVJyAypgaCwqXxomrwx8eKU=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=XmZBfZys9styChwOrYCeGlw/vHUqdkTWOjSpyFWhyqWM7vKCsWa7E0LHhjPPm0hC6unVbRABRU7Xpg4PDuAx7VuVUMsp9H+0AUCbm1pCg7KxwkhwYsG1XJMf2Yw2/MNho7dXFimQ9xAF0OGLrTVcfX8KtqF6zXcCjz6TnjXV3nyCOKEKgUIhyoDaO8G1pRTyQI+naGxBLXS6kiTvrMj50FQxX55rgCKMMukbZ0ue9JZy29wzvVcjoXlGQ9oCPCr0FWNjIdKVMt/cU+c7FMVtx0WJZNh6nsArlMUgBoqGdn4lQCsQ2TG+qalPTW8zoUxQGD8gX27ASv0J2Iqbnu78iA==
Received: from [] by with NNFMP; 10 Feb 2015 21:48:00 -0000
Received: from [] by with NNFMP; 10 Feb 2015 21:48:00 -0000
Received: from [] by with NNFMP; 10 Feb 2015 21:48:00 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: tId_3vgVM1lWbs5QvHtpoyXD..ry3abIKd_JDft6GFFSySR 1pBWcJxmTLTcul9SnhTo82fh5sm_LH5bVOH86zgKRvEw2DZhl10vaN_dhGsK J01UxZC6Fr9lm8Spkrqjb1cZl9Scdsj_arnEpXWYLaWQ_nq8YNt1XT8VLfVm LVdM5QvvbHCMyQXvfgk8kcr6.0w2kBccG5CahxB2lQ0NJaGyCRZQkip.X5yk h2HLuLCpSBu2dztk3HA69JrB9RbX9bbmERNo9zPgMl6zXp7.jLkwNaRW0a_V 18RU2cbVOLFJRg5iQ_5pMywA77g8mj15waJ4Z9Loi7ZRFmuZ8rYBF7KFN3SR 3w3mOt61OwPi3UM0f95FQ.0IcsXK76du8x2nm0wXU8WH_NWI7zw7QFPGqKYe O6zJSg8nr3whZ3f4GZbY1MhzT425CcOYkvg0nz54tNIx8uG_JIgBkxkWowrv qPJKiYAVf6rFlcbP53tpLsJ1P10VUUx4u6XXR1cLMOMq90u4eMGKk5vZmorm VCgdA.x3YW2Jwf7ug7O9pcwPrk49tpfCWONz9RYpyqNgSuHhOeTmmXi53hPV tgRpPU7iZAz5NqulTP3y.j5yU2eugKhjbRj8ytLugweweHr2.EKTzDQ6IVBt bQssZ0Rs-
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [] ( []) by (Postfix) with ESMTPSA id 3E3E71C6029 for <>; Tue, 10 Feb 2015 16:47:59 -0500 (EST)
Message-ID: <>
Date: Tue, 10 Feb 2015 16:48:08 -0500
From: David Mandelberg <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="NvX6a6Tpjkimbc7RlfbHEoARBE5P9wWxu"
Archived-At: <>
Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Feb 2015 21:48:03 -0000

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

Michael, response to your comment is below.

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.

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

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

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

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

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

David Eric Mandelberg / dseomn