On 06. 02. 20 1:58, Viktor Dukhovni wrote: > On Wed, Feb 05, 2020 at 12:05:41PM -0500, Joe Abley wrote: > >> We (PIR) are currently discussing a timeline for implementing changes >> with Afilias, who run all the back-end registry systems for ORG. >> Algorithm 8 or 13 both seem like plausible targets, but opinions from >> the community would be very welcome. > > FWIW, the momentum seems to be with algorithm 13: > > https://twitter.com/AFNIC/status/1222904523481444362 > > But if the wisdom of the crowd is not the right basis for a decision, > the considerations as I see them are: > > 1. P256(13) is generally considered equivalent to ~3072-bit > RSA in security. > > 2. P256 signatures are half the size of 1024-bit RSA signatures > (less amplification and/or truncation). > > 3. Signing with P256 is much faster than RSA. For example, on my > 25-watt (low power) 4-core 8-thread Xeon some quick informal > measurements with "openssl speed" (1.1.1d) (1 thread, 4 threads > and 8 threads) yield[1]: > > sign verify sign/s verify/s > rsa 2048 bits 0.000750s 0.000021s 1333.0 48295.7 > rsa 2048 bits 0.000225s 0.000008s 4445.0 131794.8 (4x MP) > rsa 2048 bits 0.000173s 0.000005s 5768.1 193455.0 (8x MP) > > rsa 1024 bits 0.000107s 0.000007s 9302.9 146937.3 > rsa 1024 bits 0.000034s 0.000002s 29785.5 467587.8 (4x MP) > rsa 1024 bits 0.000025s 0.000002s 40302.4 564390.1 (8x MP) > > rsa 1280 bits 0.000388s 0.000012s 2575.4 83000.6 > rsa 1280 bits 0.000124s 0.000004s 8058.4 256073.9 (4x MP) > rsa 1280 bits 0.000091s 0.000003s 10937.2 349880.0 (8x MP) > > ecdsa p256 0.0000s 0.0001s 36479.8 12455.2 > ecdsa p256 0.0000s 0.0000s 124877.2 40733.4 (4x MP) > ecdsa p256 0.0000s 0.0000s 167358.6 52250.6 (8x MP) > > 4. However, as you can see above, signature *verification* with > P256 is ~7 times slower than with 1280-bit RSA (or ~12 times > slower than with 1024-bit RSA). > > So if you're optimizing for higher security and lower packet size (and > perhaps much faster zone signing time), P256(13) is the way to go. If > however, you're concerned about resolver performance, then rsa1280 has > an advantage. > > Thus my 25W server running flat out can do ~350K rsa1280 signature > checks per second, vs. ~52K P256 signature checks per second. > > When the DANE/DNSSEC survey is running, unbound is keeping 1 core pretty > busy handling O(5K) cache misses a second. > > I don't know what fraction of the CPU cost is in the crypto vs. all the > other costs of processing the traffic. I am reluctant to increase > concurrency, lest my queries be throttled by upstream nameservers. > > The survey already has to deal with a large fraction of the domains > using P256, so these likely already dominate any crypto impact on CPU > cost, and yet I can do ~5K validated qps on a low power server also > running a Postgres database and the survey engine. The system is > somewhat less than 50% utilized while running the survey.
Anecdotal evidence: When benchmarking Knot Resolver on realistic "ISP scenarios", amount of CPU time spent on DNSSEC validation is dwarfed by all the rest. It has two reasons: - In practive most of the traffic is cache-hit. - You would be surprised how slow UDP packet processing in kernel can be ;-) Based on this anecdote RSA has no practical performance-advantage over P256. -- Petr Špaček @ CZ.NIC _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
