On 3/1/24, 11:13, "pch-b538d2...@u-1.phicoh.com on behalf of Philip Homburg" <pch-b538d2...@u-1.phicoh.com on behalf of pch-dnso...@u-1.phicoh.com> wrote:
I removed a lot of logic, as it seems dead on. But... > This would allow validators to reject any DS or DNSKEY RR set that has a > duplicate key tag. "This" refers to barring keys from having duplicate key tags. My knee-jerk response is that validators are already permitted to reject anything they want to reject. (We used to talk about the catch-all "local policy" statements in the early specs.) You don't have to bar duplicate key tags to allow validators to dump them, validators already have that "right." >Duplicate key tags in RRSIGs is a harder problem I'm not clear on what you mean. I could have RRSIG generated by the same key (binary-ily speaking, not key tag-speaking) that have different, overlapping temporal validities. If you want to draw a malicious use case, I could take an RRSIG resource record signed in January with an expiration in December for an address record that is changed in March, and replay that along with a new signature record, signed in April and valid in December. One would validate and the other not. But this isn't a key tag issue, it's a bad signing process issue. Not completely fictious one. There was a TLD whose signatures always expired on New Year's eve. Not sure if the TLD in question does this anymore, but for a number of years (at least 3), all signatures they generated expired on the next New Year's eve. >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. Heh, heh, if you make the problem simpler, then solving it is possible. Seriously, while I do believe in the need for a coherent DNSKEY resource record set, there are some multi-signer proposals that do not. If the key set has to be coherent, then someone can guard against two keys being published with the same key tag. The recovery may not be easy as you'd have to determine what key needs to be kicked and who does it and where (physically in HSMs or process-wise). I have some doubt that key tag collisions can be entirely avoided. Even if you could - you still have the probablility that someone intentionally concocts a key tag collision. Not everyone plays by the rules, especially when they don't want to. So - to me - it keeps coming back to - a validator has to make reasonable choices when it comes to using time/space/cpu to evaluate an answer. No matter whether or not the protocol "bars" duplicate key tags and whether or not signers are instructed to avoid such duplication. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
