My take on this draft: TLDR: it increases complexity for too little gain
RFC 4034 reserves two algorithms for private use (253 and 254). I have no desire to support private algorithms, and I think most people agree because since the publication of RFC in March 2005, these features have seen hardly any use. It is telling that the draft to fix the DS issue comes 20 years later. The obvious thing to do is to mark this feature as deprecated and move on. There is however the issue of experimenting with PQC algorithms and assigning code points to those algorithms. Algorithms 253 and 254 seem in an ideal position to support those experiments. Note the word 'experiments'. As far as I know there is no proposal to run production traffic using algorithms 253 and 254. If a PQC algorithm is deemed suitable for production traffic then we should allocate a code point. A direct implementation of the current DNSSEC specification may lead to DNSSEC validation errors when algorithms 253 and 254 are used. Validation errors can be avoid but then may lead to downgrade attacks. In short, draft-andrews-ds-support-for-private-algorithms fixes a real protocol issue. >From a software point of view, it is desirable to support experiments with PQC with minimal impact on the core of the DNSSEC components. At the moment (in our software) support for algorithms 253 and 254 does not exist, but can be added easily in the adaption layer between the generic DNSSEC code and the underlying crypto libraries. Support for new hash algorithms, for example SHA3, would end up in the same place. This draft changes all of that. Support for SHA-256-PRIVATE would require generic DNSSEC code to understand algorithms 253 and 254 or hacks in the adaptions layer. Neither of which are desirable for an experiment. In sort, this draft fixes real issues with the current specification of DS for algorithms 253 and 254. However, if the main use of those algorithms is expected to be experiments with PQC, then the occasional DNSSEC validation error would not invalidate the experiment. So in my opinion it would be best to abandon this draft. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
