On 8/13/25 22:03, Paul Hoffman wrote:
A different alternative is:
2c. Replace:
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.
with:
Operators of validating resolvers MUST treat DNSKEY and RRSIG records
that use RSASHA1 and RSASHA1-NSEC3-SHA1 DS records as insecure.
The leaves open the possibility of creating a chain of trust like
example.com. DS ... 13 2 ...
example.com. DNSKEY 257 3 13 ...
DNSKEY 256 3 5 ...
RRSIG DNSKEY 13 ...
example.com. A 1.2.2.3
RRSIG A 5 ...
where the SHA1-based key does not "use RSASHA1 and RSASHA1-NSEC3-SHA1 DS
records", but it introduced only within the DNSKEY RRset.
Although there is a requirement to not publish such an "algorithm switch", this is being
disputed by the multi-signer folks, and anyway "[t]his requirement applies to servers, not
validators. Validators SHOULD accept any single valid path." (RFC 6840 Section 5.11)
Also, it is not "DNSKEY and RRSIG records" that can be in secure; a response
(or entire zone) is insecure (or secure bogus or indeterminate).
Presumably, we don't want SHA1-based keys to be used in such scenarios either.
A simpler way of putting it, to me, seems to stop talking about specific record
types, and instead refer to the validation outcome's security status:
2d.
Operators of validating resolvers MUST treat DNSSEC signing algorithms
RSASHA1 and RSASHA1-NSEC3-SHA1 as unsupported, rendering responses insecure
if they cannot be validated by means a chain of trust using only other,
supported signing algorithms.
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
