Subject: Re: [sidr] preventing SKI collisions

From: David Mandelberg <[email-masked]>
Date: Mon, 05 Oct 2015 16:36:03 -0400

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/

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 6 Oct 2015 08:30:27 -0400

Speaking as regular ol’ member only.

On Oct 5, 2015, at 4:36 PM, David Mandelberg <[email-masked]> wrote:

>> that we do something different in BGPsec than what is done in the rest
> 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.

I’m ok with “warn”, but “blacklist” is a bit strong for me.  If you mean stop using that CA, i.e. remove all objects produced by that CA, then the whole tree under that CA would fall off the planet.  I think that’s a potentially large cone of consequence and I believe it should be undertaken by brains, not code.

I’d prefer a warning in the security considerations section and a recommendation to alert the operator.

—Sandy, speaking as just a regular ol’ member

---

From: Sean Turner <[email-masked]>
Date: Wed, 7 Oct 2015 09:22:40 -0400

> I’d prefer a warning in the security considerations section and a recommendation to alert the operator.

Yep let’s just put a warning in the security considerations and alert the operator.

spt

---

From: Randy Bush <[email-masked]>
Date: Wed, 07 Oct 2015 09:23:06 -0400

> I'd prefer a warning in the security considerations section and a
> recommendation to alert the operator.

please.  and put this to bed already.

randy

---

From: Rob Austein <[email-masked]>
Date: Thu, 08 Oct 2015 16:17:51 -0400

At Wed, 7 Oct 2015 09:22:40 -0400, Sean Turner wrote:
>>> 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.
>> 
>> I?m ok with ?warn?, but ?blacklist? is a bit strong for me.  If you
>> mean stop using that CA, i.e. remove all objects produced by that
>> CA, then the whole tree under that CA would fall off the planet.  I
>> think that?s a potentially large cone of consequence and I believe
>> it should be undertaken by brains, not code.
>> 
>> I?d prefer a warning in the security considerations section and a
> Yep let?s just put a warning in the security considerations and
> alert the operator.

Agreed.  "Blacklist" sounds too much like mandatory policy.
My RP, who are you to decide how much of its CPU time I should waste?