Re: [sidr] preventing SKI collisions

[David Mandelberg <[e-mail]>]

On 2015-09-16 10:38, Sean Turner wrote:
> Okay so I think we’re in agreement here that we don’t work on #3 now,
> but I’m also thinking that we should leave #1 and #2 alone for now.
> If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then
> it sounds like it's also good enough for BGPsec.  It seems really odd
> that we do something different in BGPsec than what is done in the 
> rest
> of the RPKI.  So, I’m proposing that:

I was about to argue that BGPsec's requirements for KIs are inherently 
different than the rest of the RPKI's requirements for KIs, but then I 
realized that I only thought that way because I'm implementing the 
relying party side of things and not the BGPsec-enabled router side. So 
I now agree with you that we can leave #1 and #2 alone for now, but only 
if we do #4 (which I just made up):

4. Add text warning relying parties to detect malicious CAs that cause 
too many KI collisions, and blacklist those CAs. Similarly, warn routers 
and/or rpki-rtr caches to detect AS numbers with too many public keys 
sharing the same SKI, and blacklist those AS numbers.

In both router certs and other RPKI certs, the KIs are used as an 
optimization in the selection of a public key (BGPsec) or certificate 
(RPKI) to use for BGPsec validation (BGPsec) or certificate path 
validation (RPKI). If there are too many KI collisions, then this 
optimization stops working well, and it's possible for a malicious CA to 
DoS a router (router cert SKI collisions) or relying party (CA cert SKI 
collisions). In either case, the DoS could be prevented by reducing the 
probability of collisions (your #1-3), or by detecting and ignoring the 
malicious CA (my #4).

By the way, I think your #1 might be easier than my #4, but either one 
would prevent the issue Richard discovered.

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