I've only just got caught up with the 70 or so messages on this thread. Rather than responding to individual messages, I'll just make some general remarks.
On the assertion that the collision free key tag requirements are not always easy to implement (e.g. for multi-signer configurations or the root zone), I don't think that's true. It requires a bit more coordination, but the draft offers multiple possible solutions to this. Mark Andrews and I spoke in person this week, and we will be writing out additional details on this in the next revision of the draft. In practice, many such sites already ensure that they don't have colliding key tags (albeit typically with a manual process rather than with an automated collision detection and avoidance protocol). The root zone specifically (which can be viewed as a special case of a Multi Signer Model 1 configuration with a single zone owner and a single provider) already does. Others have already mentioned this point, but I wanted to re-emphasize that one of the reasons I think we need a draft of this nature is that keytrap vulnerability measures are already deployed in the field in a variety of different ways, and this is causing unpredictable failures. Some implementations are limiting the number of collisions, others are limiting the number of signature verification failures, and in varying ways -- per data RRset, per response, per auth chain depth; and probably in other ways we don't even know yet. Things are all over the place. Our proposal is to outlaw collisions entirely to bring back uniformity and predictable behavior. Yes, this could also be achieved by limiting the number of collisions to a small number rather than zero. But the other reason for zero collisions is that we want the protocol to be as efficient as possible. I've always thought the trial and error verification design of a set of candidate keys was a bit silly. This design combined with the failure of resolver implementations to sensibly bound work directly led to keytrap. The key tag should uniquely identify a key. Discussions with many folks over the last year have confirmed to me that many protocol designers agree with this point of view. And why would any zone owner deploy a configuration where resolvers are potentially required to perform unnecessary signature verifications for every response from that zone? Both the DNSSEC protocol and key generation procedures should prevent that. (Note that the keytrap authors have also proposed a collision free key identifier design, involving new RR types, IDKEY/IDDS at last summer's ANRW. The current draft was partly a reaction to that proposal as we felt that the former was a more radical change that would take much longer to deploy). Getting to collision free key tag enforcement will take some time, I agree. We could limit the collision free semantics only to new algorithms going forward. For existing algorithms, we could punt. Or introduce new aliases/numbers (which I know some folks don't like, though we've done that successfully with algs 6 and 7 for NSEC3), or target a future flag date for enforcement (and I know some folks hate flag days - Paul Wouters gave me a tshirt on that subject this week! :) Mark and I are both at IETF123 in Madrid this week, and would be happy to chat in-person on this topic. Shumon.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
