From: DNSOP <dnsop-boun...@ietf.org> on behalf of Bob Harold <rharo...@umich.edu> Date: Tuesday, February 20, 2024 at 09:53 To: Edward Lewis <edward.le...@icann.org> Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Paul Wouters <p...@nohats.ca> Subject: Re: [DNSOP] Detecting, regeneration and avoidance was Re: [Ext] About key tags
>But if I have a 'standby' DS record, to allow faster rollover if a key is >compromised, >then there will always be two DS records. And without a key tag or >equivalent, resolvers >would have to do extra work to check the DS record because they would not know >which one was active. Key tags add efficiency, we just need to handle >occasional collisions. Instead of a hash algorithm and hash value, the key’s bit’s itself could be in the DS resource record. You could drop a field from the DS resource record but make it longer. Not to get into a history lesson but to add context, in the early iterations of DNSSEC, before there was the DNSKEY, there was the KEY resource record. Around that time there was no DS resource record. I’ll inject that the DS resource record, with the hash, was proposed to address design issues and I have to be honest I’ve forgotten some of them. I believe one was the fear that an advertised public key would enable reverse engineering of the private key, so to stop that from happening, only a hash was used. I could be wrong on that reasoning - and I won’t vouch for the idea that one can reverse engineer the private key from just the public key (and even with some data and signature samples), as if that were possible, public key cryptography wouldn’t work at all. There were concerns about sending the public key to the parent. I do recall that I felt strongly the child should only send the hash but operating registries began requiring the keys so that they would calculate the hash. There was also concern about how to signal that a child was not signing with DNSSEC, something had to be at the parent. Looking back, I can’t figure out why we didn’t just include the whole key in the DS resource record. Perhaps we didn’t want to recreate the NS at parent and at child situation.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
