Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Michael Sinatra <michael@brokendns.net> Tue, 27 March 2018 18:20 UTC

Return-Path: <michael@brokendns.net>
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 9D2EF12D7E2 for <dnsop@ietfa.amsl.com>; Tue, 27 Mar 2018 11:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4zodOK9U0kq4 for <dnsop@ietfa.amsl.com>; Tue, 27 Mar 2018 11:20:55 -0700 (PDT)
Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1BD129C6B for <dnsop@ietf.org>; Tue, 27 Mar 2018 11:20:55 -0700 (PDT)
Received: from elwha.brokendns.net (elwha.brokendns.net [206.125.172.202]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id w2RIKqbS070913 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 27 Mar 2018 14:20:53 -0400 (EDT) (envelope-from michael@brokendns.net)
Received: from nofx.lbl.gov (nofx.lbl.gov [IPv6:2620:83:8000:107::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id 5022040A30; Tue, 27 Mar 2018 11:20:51 -0700 (PDT)
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: dnsop@ietf.org
References: <EBE54422-0A97-4B33-BD55-01CACF1F272A@isc.org> <525a5b1f-07a6-1fb1-aada-5a5dc07db110@brokendns.net> <524A0C89-F1CE-4D36-BB45-1FDFF210E656@vpnc.org> <09435ace-eadf-d5cb-bd00-c007a9126316@brokendns.net> <BC4B7324-28B9-4EB4-9BCC-9C85D141E34B@vpnc.org>
From: Michael Sinatra <michael@brokendns.net>
Message-ID: <c5c739a3-a315-2220-a717-0f02dafc3543@brokendns.net>
Date: Tue, 27 Mar 2018 11:39:51 -0700
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <BC4B7324-28B9-4EB4-9BCC-9C85D141E34B@vpnc.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [162.217.113.18]); Tue, 27 Mar 2018 14:20:53 -0400 (EDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Zt-KxWsymYfEU9E_ZmfyZ3X0hDg>
Subject: Re: [DNSOP] New Version of draft-ietf-dnsop-algorithm-update-00: Algorithm Implementation Requirements and Usage Guidance for DNSSEC
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Mar 2018 18:20:58 -0000


On 03/27/18 10:22, Paul Hoffman wrote:
> On 27 Mar 2018, at 10:21, Michael Sinatra wrote:
> 
>> My goal is to basically avoid confusion and just tell people to use the
>> strongest algorithm they can reasonably use.  I.e. follow the CNSA
>> recommendations and don't spend a lot of time thinking about the
>> application.
> 
> The CNSA will likely be updated in the future to actually deal with the
> issues, or be supplanted altogether with something from a different
> agency that is better written. Telling people "just follow this
> poorly-worded doc" is not what this WG should be doing.

Hi Paul:

To be clear, I am not asking the WG to refer to the CNSA.  I am merely
asking the WG not to create something that can be construed as
fundamentally inconsistent with it.

I propose replacing:

"ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
offers only a little advantage over ECDSAP256SHA256 and has not seen
wide deployment, so the usage of this algorithm is discouraged,
especially for signing."

WITH:

"ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
offers a modest security advantage over ECDSAP256SHA256 (192-bits of
strength versus 128-bits).  For most applications of DNSSEC,
ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
future, and is therefore recommended for signing.  While it is unlikely
for a DNSSEC use case which requires 192-bit security strength to arise,
ECDSA384SHA384 is provided for such applications and it MAY be used for
signing in these cases."

This also makes the discussion in this draft more consistent with RFC
6605's discussion of ECDSAP384SHA384 and RFC 8080's discussion of Ed448.

michael