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

Paul Wouters <paul@nohats.ca> Thu, 07 June 2018 18:02 UTC

Return-Path: <paul@nohats.ca>
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 E4530130F66 for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 11:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 yD_jdDWoKlSP for <dnsop@ietfa.amsl.com>; Thu, 7 Jun 2018 11:02:29 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 6260A130E60 for <dnsop@ietf.org>; Thu, 7 Jun 2018 11:02:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 411tfp1N1HzF4S for <dnsop@ietf.org>; Thu, 7 Jun 2018 20:02:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1528394546; bh=c/YgFZSyFJQ86uKcIktXhMQ3w4t/jV1RGhb0wpOjCIk=; h=Date:From:To:Subject:In-Reply-To:References; b=C1Cb/W8AYpxhomcPwBok2KSVLBwy4WY3HHH08PfkfmjwmbIXfqWVdzRjv0fN07S+x bS7YRQ8Fi1Jg8lOAxOt6cXmoyRzFA7d659MRWNqT2ehFdjLRYpZSZO84BEtHJyPMUy MvkoRcDfzSest4G3Ee7kCyVm0fZzFdOalwi3AS2E=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Rp8V9LoNZr0z for <dnsop@ietf.org>; Thu, 7 Jun 2018 20:02:24 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Thu, 7 Jun 2018 20:02:24 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E7AFA700EC; Thu, 7 Jun 2018 14:02:23 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E7AFA700EC
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E204C400169C for <dnsop@ietf.org>; Thu, 7 Jun 2018 14:02:23 -0400 (EDT)
Date: Thu, 7 Jun 2018 14:02:23 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <20180607063933.GD3322@mournblade.imrryr.org>
Message-ID: <alpine.LRH.2.21.1806071357470.31594@bofh.nohats.ca>
References: <152822474090.19277.2490524843716126021.idtracker@ietfa.amsl.com> <D1867A13-540C-4154-B70A-C057428DFA26@isc.org> <20180607063933.GD3322@mournblade.imrryr.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_PUHLcheGW58shA0_Rg0XQ9H5R4>
Subject: Re: [DNSOP] Fwd: 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 18:02:35 -0000

On Thu, 7 Jun 2018, Viktor Dukhovni wrote:

>    Seeing that Ed25519 is RECOMMENDED for signing makes me think that
>    this software implementation advice, since signing zones with
>    Ed25519 seems presently premature.

Unfortunately we had to reduce the complexity of algorithm entries into
the table. My original test used the modifiers common in other WG, and
we could have used MUST on the validation part and SHOULD+ on the
signer part, indicating this is an up and coming algorithm.

But with the limited options we have now, we can only say RECOMMENDED,
because saying "NOT RECOMMENDED" will make people think this algo is bad
instead of thinking "it is a little too soon for this algorithm".

> 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.

It is not about finding implementations that don't support it. It is
about attempting to reduce a long tail of out of fashion algorithms.
We did a bad a job when adding new ones and we are trying to limit
these for current and future use.

>    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:

At the time, we were more concerned about packet size than CPU usage.

>    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?)

I hope it is now clearer why we are doing this?

Paul