On 22/07/2024 16:28, Viktor Dukhovni wrote:
On Mon, Jul 22, 2024 at 11:58:03AM +0100, John Dickinson wrote:

The TLD .it is signed with Algorithm 10 / RSASHA512.
(https://dnsviz.net/d/it/Zp348A/dnssec/)
RFC 8624 say, RSASHA512 is NOT RECOMMENDED. Does anybody know if .it
will change it's algorithm some day?

The table in RFC8624 is about implementation recommendations not which
algorithm you use for signing.

Well, I read the column headings as precisely about what to use for
signing or verification, the word "implementation" in the first
paragraph looks suboptimal, because the table contains operational
practice advice, more so than software implementation support.

    https://datatracker.ietf.org/doc/html/rfc8624#section-3.1

    +--------+--------------------+-----------------+-------------------+
    | 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       |
    +--------+--------------------+-----------------+-------------------+


Hi Viktor,

Section 1.3 Document Audience is all about implementations.

If table was what to use for signing then wouldn't that imply you MUST sign with both 8 and 13, which wouldn't make much sense to me. On the other hand, saying that a signer MUST be capable of signing with both 8 and 13 is fine.

So while the TLDs in question should switch to 8 or 13, they're likely
to see more risk in performing a rollover than in sticking with a
deprecated algorithm. :-(

Agreed.

regards
John

--
John Dickinson Sinodun Internet Technologies Ltd.

_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to