On Sun, 14 Aug 2022, Tim Wicinski wrote:
Speaking as a chair, and a fan of 8624, I would welcome a 8624-bis document to
appear.
(I think I expressed this to others than myself, but....).
The table in 3.1 is so clear in what to use and not use.
Right, but there is a reason the original author(s) (well, me at least)
haven't done this yet. Look at the two main tables:
+--------+--------------------+-----------------+-------------------+
| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |
+--------+--------------------+-----------------+-------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | NOT RECOMMENDED | MUST |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
| 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED |
+--------+--------------------+-----------------+-------------------+
So I think we could move ECC-GOST validation to MUST NOT because it is
not really deployed anywhere anyway.
Then the only change here would be _if_ we conclude SHA1 should change
from NOT RECOMMENDED / MUST to NOT RECOMMENDED / SHOULD|MAY|MUST NOT
and for DS records:
+--------+-----------------+-------------------+-------------------+
| Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation |
+--------+-----------------+-------------------+-------------------+
| 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] |
| 1 | SHA-1 | MUST NOT | MUST |
| 2 | SHA-256 | MUST | MUST |
| 3 | GOST R 34.11-94 | MUST NOT | MAY |
| 4 | SHA-384 | MAY | RECOMMENDED |
+--------+-----------------+-------------------+-------------------+
The changes here would be similar. GOST can get updated to MUST NOT for
validation and the question on SHA-1 validation from MUST to SHOULD or
MAY ?
Note that there is an updated GOST draft in the pipeline, it would make
sense to make all the GOST changes at once when the draft becomes RFC.
The new GOST could be mentioned at the MAY level, or it could keep in
sync with TLS and add it as NOT RECOMMENDED.
So I think we should discuss about the SHA1 status for sure, and if the
consensus is to change it, then update this document instead of writing
a SHA-1 only document that contains a lot of boilerplate for basically
one sentence:
This document retires the use of SHA-1 within DNSSEC.
And it is a statement I think is too blunt. 8624 already tells people it
is NOT RECOMMENDED to create SHA1 based records and to migrate away. It
does tell people that validators should still use it at the MUST level.
I also strongly disagree with this:
This document increases the security of the DNSSEC ecosystem by
deprecating algorithms that make use of older algorithms with SHA-1
derived uses.
It does NOT increase security to ignore SHA1 based RRSIGs or DS
records, because then the zones that use those become insecure and
are then trivially spoofed without even needing the effort of "breaking
SHA1". We have had a long thread based on Tony Finch's argument he
can stuff things into DNS well enough to break it, but I have so far
not been convinced it is possible based on those discussions. But even
if it is, that is still more work then not needing to do anything.
This is why I also think 8624bis is better than a stand-alone document,
as it takes into account security effects, market deployment, and
trying to push the deployments to where we want it to go, instead of just
issuing a document the current deployments have no choice but to ignore.
I think our decision should be based on the deplyment statistics of SHA1
based zones and keys. I'd love to see the trending statistics from
Viktor to guide us here. Last time we looked it was still in the order
of 40% or so ?
We need to be in the tail-end before we change validation recommendations
for SHA1 from MUST to SHOULD or MAY or MUST NOT. I do think unlike
TLS/IPsec, we should move faster once we start moving, because once it
becomes optional on the resolver, the entire algorithm has become
untrustworthy because unlike TLS/IPsec, there is no algorithm
negotiation happening.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
