Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt

[Ondřej Surý <[e-mail]>]

> On 7 Jun 2018, at 08:39, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Tue, Jun 05, 2018 at 09:02:07PM +0200, Ondřej Surý wrote:
> 
>> Could I ask for more reviews, so we can progress this document forward?
>> 
> 
> A couple of quick comments:
> 
> 1.  Perhaps it might not be clear to all readers whether the
>    table in Section 3.1 is *software* implementation advice or
>    operational deployment advice?
> 
>    Seeing that Ed25519 is RECOMMENDED for signing makes me think that
>    this software implementation advice, since signing zones with
>    Ed25519 seems presently premature.

It is definitely *software* implementors advice.  Good point!

> 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.  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:
> 
>      type  16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
>    sha256 39497.53k   114122.11k   266197.16k   395693.40k   461698.39k  469658.28k
>    sha512 30863.64k   122424.60k   278926.37k   495961.09k   643754.67k  654338.73k
> 
>    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?)

This particular author believes that the DNSSEC should move to ECC,
so there’s a high cost associated with KSK algorithm rollover. So, if people
are going to change to “stronger” (whatever this means in DNSSEC context)
algorithm they should be strongly encouraged to change the algorithm
to ECDSA256 (for now).

Thanks for the review!
Ondrej
--
Ondřej Surý
[e-mail]