> There is a trick available which might or might not be a good > idea: > > Define a single DNSSEC "algorithm" (with a given assinged number) > which in fact uses different cryptographic algorithms for KSK > and ZSK, respectively.
The first question that came to my mind is whether this can be considered secure. Or, who decide whether this is secure enough? In that sense a single DNSSEC algorithm would be good because it would force a security analysis of this combination. > Regarding relaxing RFC 4035 requirements: I think it's pretty > difficult. For now, I'd like to see draft-huque-dnsop-multi-alg-rules > move forward. Yet your question seem to be slightly different. Regarding 4035, there are operational issues and there are software issues. The traditional problem with different algorithms for KSK and ZSK is that a validator may support the KSK algorithm and then conclude DNSSEC bogus if it doesn't suport the ZSK algorithm. That can be solved with the required that any software that supports the PQC KSK algorithm also has to support the traditional ZSK algorithm. A simple line in a doucment that updates RFC 4035. The software problems are first signers that have no support at all for KSK and ZSK with different algorithms. Adding a PQC algorithm is easy compared to introducing this split. Other software may take RFC 4035 literally and check whether the KSK and ZSK have the same algorithm. This could be online tools such as dnsviz or offline zone checkers. Or even DNSSEC validators. So we would have to figure out how much code has to change to make such a split possible. Note that many of the same code changes would also have to happen for draft-huque-dnsop-multi-alg-rules. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
