> First, forbidding key tag collisions is not controversial, the > trouble is that forbidding them is not feasible and, more > importantly, does not prevent them from happening. Validators > still need to guard themselves. Forbidding is what I'm objecting > to - discouraging them, limiting them is fine, but forbidding > is beyond feasibility. > > > Second, directing validators to fail at the first sign of failure > increases the brittleness of the protocol.
It has been shown many times that, certainly in a security context, "be liberal in what you accept" leads to all kinds of problems that later on. Which leads to fragile systems because they have to create security out of chaos. If there is more than one way to do something, then it becomes harder to reason about the system. At the same time cryptography is brittle by nature. Either you get the details right, or you have a failure. There is very room for gracefull degradation. As far as I can tell, there are three places where a duplicate key tag can show up: 1) In the DS RR set 2) In the DNSKEY RR set 3) In a set of RRSIGs associated with an RR set. The first two can not happen by accident, cannot be the result of a temporary inconsistency. Both the DS and the DNSKEY RR sets have to be signed. If we would change to rules on duplicate key tags then all signers can be fixed to never sign a DS or DNSKEY RR set that has a duplicate key tag. Then that would prevent them from showing up on the wire. This would allow validators to reject any DS or DNSKEY RR set that has a duplicate key tag. Note that we expect both signers and validators to do a lot of complicate things that have to be exactly right otherwise DNSSEC validation fails. Requiring key tags to be unique is not a particular hard requirement on a signer. Duplicate key tags in RRSIGs is a harder problem. RRSIGs do not come in sets. However, if every DNSKEY in an RR set has a unique key tag, then there is no reason for an authoritative to have RRSIGs with duplicate key tags in an answer, which in turn allows recursors to reject such answers when received, which in turn allows validators to reject such answers when validating. Now all of this is at the DNSSEC protocol level. At this level guaranteeing unique key tags is doable and quite easy. The hard part starts when (in a multi signer setup) a signer wants to insert a DNSKEY into an RR set where that would lead to a duplicate key tag. Then the signer has to back off and come back with a different key. The trade off is that key tag collisions is only a small part of all possible DoS attacks on a validator. If we require all signers to avoid duplicate key tags only to get rid of one possible DoS, but many attacks continue to exist, then it may not be worth the effort. But for the simple question, would requiring unique key tags in DNSSEC be doable without significant negative effects, then I think the answer is yes. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
