On Oct 06, 2015, at 08:30, Sandra Murphy <[email protected]> wrote: > Speaking as regular ol’ member only. > > On Oct 5, 2015, at 4:36 PM, David Mandelberg <[email protected]> wrote: > >> 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. > > 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.
Yep let’s just put a warning in the security considerations and alert the operator. spt _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
