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

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

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ý
[e-mail]

> On 7 Jun 2018, at 17:28, Ondřej Surý <[e-mail]> wrote:
> 
>> 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]