On 20/03/15 21:20, "Rob Austein" <s...@hactrn.net> wrote:
>At Fri, 20 Mar 2015 12:35:42 -0500, Randy Bush wrote: >> >> > I?ll caveat this by saying I am definitely not hard over on this, but >> > I thought I?d bring it up: Should we switch to a SHA-256-based key >> > identifier? >> >> all the kool kids are doing that > >Not sure it's worth making an incompatible change. We may be facing problems when trying to certify RPKI software inside real customers. My experience with customers such as banks and some BGP networks (think about SWIFT) is that their security check-list is very-very hardcoded. If you have a non-compliance, it will delay your project for months/years and will add a lot of grey hairs to the project teams. So, if SHA-1 is officially deprecated (or de-facto as it is happening now) and makes it to these security-compliance check-lists, we will have no alternative from a practical view if we want people to use the technology (even if it does not introduce real enhancements.) Roque > >The key identifier isn't used for integrity checks, it's just the name >of a sort of virtual hash bucket which we use as one of the criteria >for pruning irrelevant candidate objects before we get all the way to >doing expensive signature checks. An attacker can achieve the same >effect just by inserting whatever attack string seems interesting in >the key identifier field, regardless of digest algorithm, unless >validation code also computes the key identifier digest itself and >checks that digest against the key identifier of the object under >inspection. > >My understanding is that all the current validation implementations do >in fact check key identifier digests (mostly because BBN's creatively >evil test suite whines at us if we don't detect such errors), which is >both good and bad: it's good, because it makes the DoS attack >described above harder (more precisely, it trades a small increase in >the known fixed cost per object against the risk of the DoS attack), >but it's bad because all this code knows which digest algorithm we're >using to generate key identifiers and will care if we change that >algorithm, rather than treating key identifiers as an opaque blobs. > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
