Re: [dns-operations] Filtering policy: false positive rate
--- Begin Message --- I think the examples being used in this thread are too narrow. In RPZ a firewall rule might trigger on something other than the QNAME. For example the trigger could be one of the NSDNAMEs in the resolution path, or on the address (A or ) associated with some NSDNAME in the resolution path, or on the address (A or ) of an answer. The meaning of "false" in the term "false positive" quickly goes out of scope. What we have are rules that trigger on nothing, others that trigger on the wrong thing, some that trigger on the right thing, and some that trigger on too much. Also I wish everybody would stop saying "blocking". This isn't always that. We filter DNS content because it's the gateway to much harm, and as we learn about harms, we either monitor, or drop, or redirect, or "block" (if the trigger happens to be on the QNAME in which case we can replace the real answer with an NXDOMAIN) the DNS paths to those harms. NXDOMAIN insertion is usually unwise for non-QNAME triggers. -- P Vixie --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation
On 2/8/24, 10:40, "dns-operations on behalf of Viktor Dukhovni" wrote: The chances of a remotely possibly event happening is 100% once it happens. __ So long as a hash is shorter than the data it covers, there's a chance there will be a collision. Just a general statement. >There is no issue with DS record confusion. I think you are underestimating how an operational step may go wrong. In a previous gig, the crew that had terminal access to the DNS machinery were on a different floor than the crew that was in charge with contacting IANA. There was a time when all of the first crew members assumed that one of the others in their crew told someone in the other crew to change the DS record. Oops. What I can see happening is ... having an old KSK tagged 11211 in the DS. The new KSK is also tagged 11211 and is added to the DS set. No issue there. A few weeks later, when the old key is to be retired, someone says "pull 11211" because that's easier than reading out the hash value. > And even if two keys produced the same DS record, that'd be fine too, just > publish one DS >record in support of both! The only theoretical risk is erroneously >publishing two identical RRs in the DS RRset, which is not allowed, >and validators may balk... In practice, this won't happen. The protocol doesn't care. It’s those who are doing the key management may mix them up. The convenience of 5 digit tags engenders laziness when it comes to automation - you'd have to script up something that checks hashes or fill keys, but you might not script up something that is only 5 digits long. I've seen that in action...at a root cause analysis meeting...when the issue was caused by the tech typing something in hex as opposed to using a fancy GUI because the budget didn't include the GUI update this time around. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation
On Thu, Feb 08, 2024 at 12:24:08PM +, Edward Lewis wrote: > Between non-unique key tags and the possibility of hash collisions, > it's possible two DS resource records could share either a key tag or > a hash representing different keys. From this, I wish we hadn't > defined the key tag field - and maybe stuck with the entire key in the > DS resource record. Over the long term, ... I see things differently. Collisions in SHA2-256 (with SHA1 in DS records being deprecated for some time now), would be major news indeed. There's not even a hint of such collisions being found in the next few decades. SHA1 collisions are of course a possibility, but require considerable computing resources and don't just happen "at random" (as is the case with key tags). There is no issue with DS record confusion. And even if two keys produced the same DS record, that'd be fine too, just publish one DS record in support of both! The only theoretical risk is erroneously publishing two identical RRs in the DS RRset, which is not allowed, and validators may balk... In practice, this won't happen. -- Viktor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] A follow upRe: [Ext] Re: .RU zone failed ZSK rotation
In my data, I don't see the colliding key tags involved, but historically, RU had two other keys share a key tag value - but not at the same time. Here are parts of the data I have - the last shown field is the start of the public key's bits (which show these are different keys). "RU.","DNSKEY","2019-11-20","2020-02-21" ,"ZONE","DNSSEC","RSASHA256","1024","52263","LARGE","AwEAAc1yxFp79bw... "RU.","DNSKEY","2024-01-26","2024-02-07","ZONE","DNSSEC","RSASHA256","1024","52263","LARGE","AwEAAbjj3GP0TUw... Key tags do collide, but rarely (so far) at the same time. I haven't quantified this, I just happened to look to see if my data included the two keys that caused the problem but only ran across this example. On 2/8/24, 07:24, "Edward Lewis" wrote: Very interesting. There have been two cases since 2011 of a TLD having two published DNSKEY resource records sharing the same key_tag. The first in 2018/2019 involved a TLD having a KSK and ZSK share. I didn't notice while it was happening, but found it when testing some code I have to visualize (make charts of) key lifetimes. As the testing was during the pandemic, I never had the chance to track down the TLD operators to get the story. Noting that "no one noticed" it was apparent in my data that they realized it and addressed the situation (because they retired one of the keys earlier than their pattern). The second time was in January 2024 (last month), when another TLD had two ZSK's with the same DNS Security Algorithm but different lengths (RSA). I saw this while it was happening and slipped a note to a potential contact, didn't get feedback, and the conflict went away ahead of a patterned change. I was told that the TLD is in transition, which may or may not be a factor (in the key_tag collision or "fix"). Again, in this situation, I'll note that "no one noticed" except a researcher looking for this (me) and the staff there. Colliding key tags are not an issue for the validation code, at least they shouldn't be. Protocol developers have known that key tags, being 16-bits, cannot be assumed to be unique, they are just hints. Back in the day, colliding key tags were discussed at 950 Charter in Redwood City (the old BIND building) and "fixed" by the writer of dnssec-keygen (at the time the only DNSKEY resource record generating code available) telling us he's add a clause in the code - if a new key shared a key tag with another key "in the directory of keys", the new key would be deleted, and key generation started again. This rule was never documented so hearing colliding keys now that we have more code bases could (should?) be expected. The problem with colliding key tags is in key management. I said this yesterday in a side conversation, not yet knowing of the .RU situation. I imagined someone saying "pull key 11211" and the at-the-keyboard tech pulling the wrong one. Looks like this happened (although probably automated in code). The upshot - when DNSSEC code pulls keys based on key tag, it should expect to get a set of keys, not a single key. Between non-unique key tags and the possibility of hash collisions, it's possible two DS resource records could share either a key tag or a hash representing different keys. From this, I wish we hadn't defined the key tag field - and maybe stuck with the entire key in the DS resource record. Over the long term, ... I see things differently. On 2/8/24, 04:02, "dns-operations on behalf of Stephane Bortzmeyer" wrote: On Wed, Jan 31, 2024 at 04:37:02PM +0200, Phil Kulin wrote a message of 56 lines which said: > Done. New serial number 4058860. New active ZSK > https://dnsviz.net/d/ru/ZbpWZg/dnssec/ There is now a detailed technical post-mortem. These official explanations fit the facts that we observed. Nice bug. https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation
Very interesting. There have been two cases since 2011 of a TLD having two published DNSKEY resource records sharing the same key_tag. The first in 2018/2019 involved a TLD having a KSK and ZSK share. I didn't notice while it was happening, but found it when testing some code I have to visualize (make charts of) key lifetimes. As the testing was during the pandemic, I never had the chance to track down the TLD operators to get the story. Noting that "no one noticed" it was apparent in my data that they realized it and addressed the situation (because they retired one of the keys earlier than their pattern). The second time was in January 2024 (last month), when another TLD had two ZSK's with the same DNS Security Algorithm but different lengths (RSA). I saw this while it was happening and slipped a note to a potential contact, didn't get feedback, and the conflict went away ahead of a patterned change. I was told that the TLD is in transition, which may or may not be a factor (in the key_tag collision or "fix"). Again, in this situation, I'll note that "no one noticed" except a researcher looking for this (me) and the staff there. Colliding key tags are not an issue for the validation code, at least they shouldn't be. Protocol developers have known that key tags, being 16-bits, cannot be assumed to be unique, they are just hints. Back in the day, colliding key tags were discussed at 950 Charter in Redwood City (the old BIND building) and "fixed" by the writer of dnssec-keygen (at the time the only DNSKEY resource record generating code available) telling us he's add a clause in the code - if a new key shared a key tag with another key "in the directory of keys", the new key would be deleted, and key generation started again. This rule was never documented so hearing colliding keys now that we have more code bases could (should?) be expected. The problem with colliding key tags is in key management. I said this yesterday in a side conversation, not yet knowing of the .RU situation. I imagined someone saying "pull key 11211" and the at-the-keyboard tech pulling the wrong one. Looks like this happened (although probably automated in code). The upshot - when DNSSEC code pulls keys based on key tag, it should expect to get a set of keys, not a single key. Between non-unique key tags and the possibility of hash collisions, it's possible two DS resource records could share either a key tag or a hash representing different keys. From this, I wish we hadn't defined the key tag field - and maybe stuck with the entire key in the DS resource record. Over the long term, ... I see things differently. On 2/8/24, 04:02, "dns-operations on behalf of Stephane Bortzmeyer" wrote: On Wed, Jan 31, 2024 at 04:37:02PM +0200, Phil Kulin wrote a message of 56 lines which said: > Done. New serial number 4058860. New active ZSK > https://dnsviz.net/d/ru/ZbpWZg/dnssec/ There is now a detailed technical post-mortem. These official explanations fit the facts that we observed. Nice bug. https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Filtering policy: false positive rate
--- Begin Message --- On 06/02/2024 17.06, Peter Thomassen wrote: Then, how to define a false positive rate? Look at all blocked queries, and do a post-hoc investigation? How about popularity -- should one factor in that blocking *.ddns.net is more severe than blocking *.blank.page? I.e., is it a ratio of blocked/total queries, or blocked/total names? Yes, primarily post-hoc I expect - I mean, if we could easily recognize false positives in advance, we'd do that during the blocking, right? I'd do this statistically. Take a sample from the blocked names. You could weight the names with whatever you like when choosing among them, e.g. the mentioned popularity by unique IPs querying them. Then evaluate the sample in some better way, probably by a human. You could mix in a sample from non-blocked names, too (say [1]). I think it's not difficult to design these measurements in a way that you get an OK ratio of complexity (and human work) vs. precision of the false-positive estimate. Actually I suspect that it's probably *not* worth trying to affect the choice of the evaluated sample by reports from users, as it's probably very hard to get statistically correct-ish numbers out of that. [1] https://en.wikipedia.org/wiki/Scientific_control#Controlled_experiments (reposted from a correct e-mail address; Peter will probably get a duplicate) --Vladimir | knot-resolver.cz --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .RU zone failed ZSK rotation
On Wed, Jan 31, 2024 at 04:37:02PM +0200, Phil Kulin wrote a message of 56 lines which said: > Done. New serial number 4058860. New active ZSK > https://dnsviz.net/d/ru/ZbpWZg/dnssec/ There is now a detailed technical post-mortem. These official explanations fit the facts that we observed. Nice bug. https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
