[dns-operations] .ORG still using SHA-1 DNSKEYs
ietf-dane at dukhovni.org
Thu Feb 6 00:58:26 UTC 2020
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:
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:
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
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.
 I rebuit OpenSSL from source, adding an option to test rsa1280.
More information about the dns-operations