Oh, looking at the text just before the table it says:
<t>
Implemenation recommendations for DNSKEY algorithms <xref
target="DNSKEY-IANA"/>.
</t>
I am open to suggestions go to improve this text to emphasize that it is
implementation advice,
but apart from typo :), I think it does says “Implementation”...
Ondrej
--
Ondřej Surý
[email protected]
> On 7 Jun 2018, at 17:28, Ondřej Surý <[email protected]> wrote:
>
>> On 7 Jun 2018, at 08:39, Viktor Dukhovni <[email protected]> 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ý
> [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
