I may not be guru working 10 years on DNS, but I know difference between algorithm 5 and algorithm 7. I even think why 7 were required to keep backward compatibility.
What I mean here is NSEC3 hash algorithm: https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 I thought it is not a problem, because it contains multiple iterations. Yet popular TLD has iterations==0. This is about how hash of name is created from original Next Hashed Owner Name. No other algorithm for this is defined. My conclusion is owner name hash is not security sensitive. But I never saw that written in and RFC I read. I cannot say I read or know all relevant drafts. Is it obvious to everyone but me? This is primary reason why I cannot accept ever failing SHA-1 digest from crypto library. RHEL7 in FIPS mode failed when MD5 were used. That helped to catch whatever is using md5, thus might be insecure. This must not happen with SHA-1, because NSEC3 does not have any equivalent and cannot work without it. Regardless used key algorithm, unless I am mistaken. On 3/23/22 19:21, Brian Dickson wrote: > > > On Wed, Mar 23, 2022 at 9:22 AM Petr Menšík <pemen...@redhat.com> wrote: > > Because NSEC3 algorithm still does not have any alternative to > SHA-1, hard crypto failure would be blocker for any our DNS > products. I haven't heard about it even being considered this way. > > > I think this is a relatively common misconception. (I recently > discovered that I also misunderstood the situation.) > > The first couple of algorithms specifically meant for NSEC3 use were > basically duplicates of algorithms that were NSEC-only, with new > algorithm numbers. > As I understand it, this was to ensure interoperability, in part due > to earlier implementations which would not be aware of NSEC3. > The new algorithms were a way of ensuring only updated software (which > could be guaranteed based on the algorithms being "new") would be > expected to understand (i.e. validate) NSEC3. > > After that point, all new algorithms are both NSEC and NSEC3. > > I believe that means you should be free to update to newer algorithms. > I would recommend both using Algorithm 13, and potentially moving away > from NSEC3 unless you have a strong reason for using it. > > Or are you talking about what algorithms your software supports, in > which case this should be simple enough (to allow NSEC3 on newer > algorithms). > > Brian -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
