On Thu, 7 Jun 2018, Viktor Dukhovni wrote:
Seeing that Ed25519 is RECOMMENDED for signing makes me think that this software implementation advice, since signing zones with Ed25519 seems presently premature.
Unfortunately we had to reduce the complexity of algorithm entries into the table. My original test used the modifiers common in other WG, and we could have used MUST on the validation part and SHOULD+ on the signer part, indicating this is an up and coming algorithm. But with the limited options we have now, we can only say RECOMMENDED, because saying "NOT RECOMMENDED" will make people think this algo is bad instead of thinking "it is a little too soon for this algorithm".
2. I see that RSA-SHA512 (algorithm 10) is not recommended for signing, and indeed it is not very widely deployed. Out of ~7.6 million signed domains I see ~72k with algorithm 10 ZSKs and KSKs, while algorithm 8 is used by ~3.6 million domains in KSKs and ZSKs (a ratio of 50:1 for alg 8 : alg 10). And yet, while it is not popular I don't see that any validators supporting RSA and SHA256 are at all likely not to support RSA and SHA512.
It is not about finding implementations that don't support it. It is about attempting to reduce a long tail of out of fashion algorithms. We did a bad a job when adding new ones and we are trying to limit these for current and future use.
And furthermore, on 64-bit systems SHA512 tends to be somewhat faster (more with larger input sizes), because it processes input in 64-bit blocks. On my x86_64 laptop, running OpenSSL 1.1.1 beta 'speed -evp', gives:
At the time, we were more concerned about packet size than CPU usage.
So I am not sure that algorithm 10 warrants discouragement so long as 8 is required. Everyone is going to have both, and they're basically the same... While the case *for* 10 is not strong, the case against 10 looks somewhat weak (does supporting 10 for signing carry a real cost?)
I hope it is now clearer why we are doing this? Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
