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

[David Mandelberg <[e-mail]>]

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 1.2.0.0/16
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
odds.

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