On Wed, 6 Jan 2021, Ben Schwartz wrote:
Also, you would end up building a list of algorithms from worst to best.
This is not always obvious. Sure, the SHA1 vs SHA2 is obvious. Would you
prefer a NIST ECC curve over a GOST ECC curve or not?
TLS implementations always have a preference order, so I think this is doable.
To be fair, they kicked out everything except AES_GCM and CHACHA20POLY1305, and
I think any preference there is based on speed and not level of security :P
Remember also that TLS ciphers are negotiated. There is no negotiation
in DNSSEC. You get what is published and have to decide whether or not
to use it. So TLS clients have other options to avoid using ciphers they
don't like.
Literally any preference order
would be more secure than the behavior recommended in RFC 6840.
Is it? Are you referring here to treating unknown (eg refused)
algorithms as insecure? The reason for that is to signal to the DNS
client that this answer had no "acceptable DNSSEC protection". This
is better than setting the AD bit on ciphers that you know and no longer
trust. Since that would signal to the application the answer was secured
by DNSSEC, but really it was not if you deemed the algorithm not
acceptable.
If you refer to what to do if one DNSKEY algorithm type is not working
and another algorithm type is, and what to do in such cases, then I
guess that behaviour is somewhat up to the client. unbound has an option
for this:
harden-algo-downgrade: <yes or no>
Harden against algorithm downgrade when multiple algorithms are
advertised in the DS record. If no, allows the weakest algo‐
rithm to validate the zone. Default is no. Zone signers must
produce zones that allow this feature to work, but sometimes
they do not, and turning this option off avoids that validation
failure.
I guess that makes this discussion a variant of the Postel Principle is
good or bad discusion.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
