[dns-operations] A follow upRe: [Ext] Re: .RU zone failed ZSK rotation

Thu Feb 8 12:38:36 UTC 2024

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" <edward.lewis at icann.org> 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" <dns-operations-bounces at dns-oarc.net on behalf of bortzmeyer at nic.fr> wrote:

        On Wed, Jan 31, 2024 at 04:37:02PM +0200,
         Phil Kulin <schors at gmail.com> 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 at lists.dns-oarc.net
        https://lists.dns-oarc.net/mailman/listinfo/dns-operations