[dns-operations] .ORG still using SHA-1 DNSKEYs

[Viktor Dukhovni]

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.

-- 
    Viktor.

[1] I rebuit OpenSSL from source, adding an option to test rsa1280.