Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

[Rob Austein <[e-mail]>]

At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote:
...
> I think this problem might be fixed if we modify the protocol to sign 
> all of the preceding signed data (rather than just the immediate, 
> previous signature).

Agreed, assuming this means adding the (theoretically invariant)
fields from the data to be signed in section 4.1 to the data to be
signed in section 4.2.

Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's AS
Number" in section 4.2, this leaves the algorithm suite identifier,
the AFI, the SAFI, and the NLRI to be added to the data to be signed
in section 4.2.  I doubt that there's any practical attack based on
fiddling with the algorithm suite identifier (I'd expect any games
there to cause validation failure, end of story), but maybe somebody
has a more twisted imagination than mine, and, given that the
algorithm suite ID is one byte long, I don't think it's worth trying
to optimize that byte out of the section 4.2 signature.

Presumably we want to keep the existing signature chaining, so I
wouldn't remove anything from the data to be signed in section 4.2,
just add the fields that are currently only present in section 4.1.

David, if this is consistent with what you meant, cool, if not, say on.