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

Ondřej Surý <ondrej@isc.org> Thu, 07 June 2018 15:30 UTC

Return-Path: <ondrej@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE41130F43 for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 08:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level:
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENvlc2r_wRR5 for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 08:30:33 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEA4130F3B for <dnsop@ietf.org>; Thu, 7 Jun 2018 08:30:33 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 642F43AB06C; Thu, 7 Jun 2018 15:30:33 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 338CC16000E; Thu, 7 Jun 2018 15:30:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1B56B160039; Thu, 7 Jun 2018 15:30:33 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b0qvMzRn5swz; Thu, 7 Jun 2018 15:30:33 +0000 (UTC)
Received: from [10.10.0.193] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 78D63160043; Thu, 7 Jun 2018 15:30:32 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
In-Reply-To: <02F14832-3483-4108-87A0-BCFCF07F2C6B@isc.org>
Date: Thu, 7 Jun 2018 17:30:30 +0200
Cc: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A350FB5-9D6C-4481-922C-B1B3215170CD@isc.org>
References: <152822474090.19277.2490524843716126021.idtracker@ietfa.amsl.com> <D1867A13-540C-4154-B70A-C057428DFA26@isc.org> <20180607063933.GD3322@mournblade.imrryr.org> <02F14832-3483-4108-87A0-BCFCF07F2C6B@isc.org>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-vyC4JmVbTWv8F5eQEfnWyjGrco>
Subject: Re: [DNSOP] New Version Notification for draft-ietf-dnsop-algorithm-update-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 15:30:39 -0000

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ý
ondrej@isc.org

> On 7 Jun 2018, at 17:28, Ondřej Surý <ondrej@isc.org> wrote:
> 
>> On 7 Jun 2018, at 08:39, Viktor Dukhovni <ietf-dane@dukhovni.org> 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ý
> ondrej@isc.org