> On Feb 23, 2021, at 1:08 PM, Ben Schwartz <bem...@google.com> wrote:
>
> The DNSSEC Strict Mode flag appears in bit $N of the DNSKEY flags field.
> If this flag is set, all records in the zone MUST be signed correctly under
> this key's specified Algorithm. A validator that receives a Strict Mode
> DNSKEY with a supported Algorithm SHOULD reject as Bogus any RRSet that
> lacks a valid RRSIG with this Algorithm.
This would harden DNSSEC against downgrade attacks in the scenario that
some widely supported algorithm loses its shine, and all the alternatives
are too new and are not yet broadly adopted.
The weak algorithm would have to still be sufficiently strong to bother
to keep publishing, thus able to withstand attacks by attackers of modest
means, and succumb only to nation-state level resources and non-trivial
costs even for these.
We should also keep in mind that DNSSEC use of algorithms is for signatures
only, and so need only resist attacks while the key is in use. There's no
need to remain secure 30+ years after the fact.
Thus, while on the face of it, downgrade-resistance is a sensible goal, and
the proposed mechanism is reasonably simple, it is not clear that it addresses
a sufficiently "dire" problem.
Our practical algorithm difficulties are:
* ~95% of domains use 0-bit keys (no DNSSEC at all)
* ~8K out of the 14.2 million signed domains are using 512-bit RSA keys
* ~2 million domains are using RSA-SHA1 (algorithm 7 primarily with 27k
using 5)
* ~1.8 million domains have SHA1 DS RRs
* ~120k domains are using "unreasonably large" 4096-bit RSA keys, also futile
given 2048-bit keys in the root zone.
* ~130k domains have 1024-bit RSA KSKs, these should be at least 1536, BCP
2048-bits.
They should be rolled more often.
* RSA ZSKs are predominatly (~7.3 million) 1024-bit, BCP is 1280. They
should
be rolled more often.
And of course we need registrars/registries that support CDS/CDNSKEY, more
attention to registrar account security, ...
So downgrade issues are quite a long way down the list of priorities.
When (and if) the quantum crypto apocalypse is more realistically in
our near future, we'll probably need to be doing DNS over QUIC to
transport large public keys and signatures over a new transport that
can effectively handle them.
That may be the time to consider whether we need to guard against
plausible downgrades from PQC to legacy PK cryptography with many
resolvers and/auth servers not yet ready to do the new thing.
Thus I look at DoQ not as a dprive mechanism, but as a hedge against
scalable QCs. In that context it may some day make sense to be
concerned about downgrades, but I think there are more immediate
issues to be addressed.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
