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

[Petr Špaček]

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