Jim Reid <j...@rfc1035.com> writes:
> Wes, I'm all for killing SHA1. Though the mechanism might need a
> rethink. We probably should have a simpler way to add/remove DNSSEC
> crypto algorithms. IIRC Paul Hoffman explained the problem a year or
> so ago when new code points were needed for the latest GOST
> algorithms: something about that could only be done with the overkill
> of a Standards Track RFC. Maybe that could get fixed and SHA1 could be
> its first victim?
I think it would take a while to fix the process, and this draft was
triggered by the discussion in the dns-operations mailing list which
puts it at a slightly higher priority. So though your suggestion is
likely something the WG should consider, I'd argue the fixing of that
shouldn't hold up us deprecating SHA-1. IMHO of course.
> As for the I-D, I think it should also say validating resolvers MUST
> NOT use SHA1-flavoured RRtypes for validation. ie Give SHA1 two shots
> to the head, just to be sure. :-)
Something like:
# Deprecating SHA-1 algorithms in DNSSEC
The SHA-1 {{RFC3685}} algorithm MUST NOT be used when creating DS records.
Validating resolvers MUST treat DS records as insecure. If no other DS
records of accepted cryptographic algorithms are available, the DNS
records below the delegation point MUST be treated as insecure.
The RSASHA1 {{RFC4034}}, DSA-NSEC3-SHA1 {{RFC5155}}, and
RSASHA1-NSEC3-SHA1 {{RFC5155}} algorithms MUST NOT be used when
creating DNSKEY and RRSIG records. Validating resolvers MUST treat
RRSIG records created from DNSKEY records using these algorithms as
insecure. If no other RRSIG records of accepted cryptographic
algorithms are available, the validating resolver MUST consider the
associated resource records as Bogus.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
