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/
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
