On 8/8/2025 18:42, Peter Thomassen wrote:
Hi Mike,
On 8/8/25 21:02, Michael StJohns wrote:
* Deprecated processing treats the deprecated records as if
they were unsupported, with the single exception that a DNSSEC
delegation into a zone that consists only of SHA1 dependent DS
records (e.g. no other delegations to the domain using non-SHA1
algorithms) is treated as if it were a secure delegation to an
insecure zone.
What does this mean? ("secure delegation to an insecure zone")
That was the phrasing we used to (say 15-20 years ago) mean:
1) parent zone was secure (e.g. all the signatures traced from a known
trust anchor and signatures were in place over all the RRSets of the
parent).
2) there was a DNS delegation to a child zone.
3) at the validly signed NSEC in the parent zone covering the delegation
point to the child zone, the NSEC record did not contain a bit for the
DS record. Indicating that the child zone was unsigned and hence
insecure. (even provably insecure).
So "secure" - the valid NSEC proof. "delegation to an insecure zone" -
missing DS record and bit in NSEC.
* Strict processing treats the deprecated records as if they
were unsupported. A zone delegation using only unsupported
algorithms is treated as Bogus per << ref>>.
If a validator does not support the (only) algorithm used by a zone,
then the zone is insecure, not bogus.
*sigh* You're right. (RFC4035 section 5.2 plus 6840 section 5.2).
I'm actually thinking this (deprecating SHA1) isn't that - or wasn't
what we intended by that. I.e., the original text was meant to cover
the case of NEW algorithms. E.g. SHA1 is neither unknown or unsupported
at this time.
I would be fine with a transition SHA1 being prohibited being treated as
Bogus. This is easy enough for parent zones to fix, and it may be the
only way to kill these off. Treating the deprecation/prohibition as
being different (worse) than unsupported seems more secure than the
alternatives. This may be a bridge too far in this discussion, but may
actually be a better choice here.
Later, Mike
Best,
Peter
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
