Speaking as regular ol’ member only. On Oct 5, 2015, at 4:36 PM, David Mandelberg <da...@mandelberg.org> 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. —Sandy, speaking as just a regular ol’ member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
