On 14/05/2024 22.57, Warren Kumari wrote:
This means that we should actually have a column per type (i.e
“Operators” and “Implementers”) crossed with a column per DNSSEC usage
type (“Signing” and “Validation”), such that for the “Domain Name
System Security (DNSSEC) Algorithm Numbers” table we would be adding
FOUR columns:
I'm not happy about splitting it for validation. I'd rather strive
towards a shared global expectation on which algorithms get supported by
validators, instead of standardizing that individual operators can tweak
this. (I hope this can be just about SHA1 at this point.)
The arguments have been posted in the recent weeks. AFAIK validator
implementations tend to have only two states for algorithms: supported
and unsupported, as that's what all the DNSSEC RFCs define. Downgrading
will make (some) security properties worse than keeping to validate with
a weak-ish algorithm. A current example is Fedora/RHEL for SHA1 stuff.
While I recognize that it's not easy for everyone to agree on support
status (of SHA1) in validators, not agreeing seems worse than either
result. In the current RFC 8624, SHA1 signing is "NOT RECOMMENDED".
With that it seems rather harsh to officially allow some validators to
downgrade these to insecure. I'd imagine that first we should
standardize some stronger discouragement of SHA1 in zones and keep that
for some time.
I can imagine the signing side split. For example, saying now that it's
not that bad for implementations to still allow to be configured with
SHA1, but strongly discourage zone operators from utilizing that. Or
encouraging SW to be able to sign with ed25519, but stating that (a few
years ago) the support in deployed validators didn't look too great, so
zone operators should be more careful.
--Vladimir | knot-resolver.cz
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
