Hi - apologies, I wasn't paying attention as I thought this would have
been a simple and clean document.
Mukund's note made me take a quick look a this. I think the document is
incomplete or ambiguous.
Please add a reference to RFC 4035.
Please add a sentence or two that says something like "Insecure, with
respect to DNSSEC, has the meaning given to it per [RFC4035], section
4.3." if that's what you mean by "insecure". I'm not sure if you meant
that or Bogus.
Should a SHA1 signature over a DS record be treated differently than a
signature over other records? E.g. Is a SHA1 signature in a signed zone
over a DS record bogus, or can it be treated as if it weren't present?
If the latter, is the subordinate zone securely insecure, or bogus?
The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms
MUST NOT be used when creating DS records. \
This is fine. But instead perhaps.:
The RSASHA1, and RSASHA-NSEC3-SHA1 algorithms MUST NOT be used when
creating DS records; authoritative servers MUST NOT serve DS RRSets
containing these records; validating resolvers MUST (SHOULD??)
ignore these records (as if unsupported) when present in a DS RRSet.
Validating resolvers MUST
treat RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure.
This paragraph should probably only talk about the signing side of the
problem - remove this or move below? Also records aren't secure or
insecure, RRSets and validations results are secure or insecure. A DS
RRSet containing both SHA1 and non SHA1 delegations signed by a non-SHA1
algorithm is secure (assuming a chain of trust) for example.
If no
other DS records of accepted cryptographic algorithms are available,
the DNS records below the delegation point MUST be treated as
insecure.
Same comment on moving - part of the resolver part. Move this to the
end. Also - pedantic - records are not secure or insecure, RRSets are.
Or delegations. "The delegation referred to by the DS record MUST
(SHOULD?? per configuration in a validating resolver) be treated as a
delegation to an insecure zone". If we treat this as if the DS RRSet
contained only unsupported algorithms, would this be the same result?
If I remember correctly, a securely insecure delegation is formed by
signing the appropriate NSEC(3) record and indicating that there is no
DS record set for the delegation point. In the case you're talking
about, the parent DS record(s) will continue to indicate the presence
of DNSKEYs, but the algorithm field would indicate only SHA1 DNSKEYs.
Do you mean that this should be treated as if the DS RRSet was not
present and that the NSEC(3) records indicated as such? You can't treat
this as an empty DS RRSet I think. My suggestion above clarifies this.
The RSASHA1 [RFC4034] and RSASHA1-NSEC3-SHA1 [RFC5155] algorithms
MUST NOT be used when creating DNSKEY and RRSIG records.
repetitive/redundant? There's also the transition thing. SHOULD NOT
from publication, MUST NOT from publication + 2 years? For all of
DNSKEY, DS and RRSIG.
Validating
resolver implementations ([RFC9499] section 10) MUST continue to
support validation using these algorithms as they are diminishing in
use but still actively in use for some domains as of this
publication. Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero
use, deployed validating resolvers MAY be configured to continue to
validate RRSIG records that use these algorithms. Validating
resolvers deployed in more security strict environments MAY treat
these RRSIG records as an unsupported algorithm.
I think this is OK, but I don't quite understand (same as Mukund I
think) the interactions between DS records and DNSKEY/RRSIG records
different treatment specified here.
Later, Mike
On 8/3/2025 03:42, Mukund Sivaraman wrote:
2. Deprecating SHA-1 from DNSSEC Signatures and Delegation RRs
[snip]
Validating resolvers MUST
treat RSASHA1 and RSASHA1-NSEC3-SHA1 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.
[snip]
Validating
resolver implementations ([RFC9499] section 10) MUST continue to
support validation using these algorithms as they are diminishing in
use but still actively in use for some domains as of this
publication. Because of RSASHA1 and RSASHA1-NSEC3-SHA1's non-zero
use, deployed validating resolvers MAY be configured to continue to
validate RRSIG records that use these algorithms. Validating
resolvers deployed in more security strict environments MAY treat
these RRSIG records as an unsupported algorithm.
Do the above two paragraphs not contradict each other on whether
validation should be performed for RSASHA1 and RSASHA1-NSEC3-SHA1?
E.g., if a DS RRset exists with a single DS RR with Algorithm=RSASHA1
mapping to a DNSKEY in the child zone with Algorithm=RSASHA1, must the
child zone be considered insecure, or could validation be attempted with
RSASHA1?
Mukund
_______________________________________________
DNSOP mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
