Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

Paul Wouters <paul@nohats.ca> Fri, 03 March 2017 22:56 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 86E97129418 for <dnsop@ietfa.amsl.com>; Fri, 3 Mar 2017 14:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 J-kkfJZ1XDfY for <dnsop@ietfa.amsl.com>; Fri, 3 Mar 2017 14:56:20 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 9EF48124281 for <dnsop@ietf.org>; Fri, 3 Mar 2017 14:56:19 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vZl0c4jbmz9K; Fri, 3 Mar 2017 23:56:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488581776; bh=PgSN1SwkbrPp4X6HbSTr4mlxh/rvAHwivAQyFFMxPhg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dreQd5Asrcup4zZn7n11+vsKIVmBgOJ5jE2rCieWXfAesppV//wfa8I2Uvwml801q DTTEB3rqifMz7BuqNsxwAvly4odP+V4rm/xbsbzqYFQ87BavsDwhq2qZyLYAqX+2F3 3iiTTeVQEIp4NgzwbASL51dPQ6SUGmx3UfUXbVf0=
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 02ZL5WSojdcI; Fri, 3 Mar 2017 23:56:15 +0100 (CET)
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; Fri, 3 Mar 2017 23:56:14 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B95B2446AEA; Fri, 3 Mar 2017 17:56:13 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B95B2446AEA
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A2F0541D9FEE; Fri, 3 Mar 2017 17:56:13 -0500 (EST)
Date: Fri, 3 Mar 2017 17:56:13 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: =?ISO-8859-2?Q?Petr_=A9pa=E8ek?= <petr.spacek@nic.cz>
In-Reply-To: <b3ff3793-0bb2-d277-c232-0068d1726c68@nic.cz>
Message-ID: <alpine.LRH.2.20.1703031747050.13761@bofh.nohats.ca>
References: <78013346-6100-f7e6-a3c8-87d2f92533d8@gmail.com> <F40B69DF-6391-4008-A7CD-C85277952D8A@dnss.ec> <alpine.LRH.2.20.1702281627360.22841@bofh.nohats.ca> <920390D7-BFF8-4680-B2D8-488777671DCA@dnss.ec> <alpine.LRH.2.20.1702282052220.28866@bofh.nohats.ca> <AC4C0368-1454-4718-95AF-BB4DDECEF17E@dnss.ec> <alpine.LRH.2.20.1703011221400.15273@bofh.nohats.ca> <76B12F6D-9D53-4FEB-974D-BB4D6DB02F0B@dnss.ec> <alpine.LRH.2.20.1703021223170.10405@bofh.nohats.ca> <b3ff3793-0bb2-d277-c232-0068d1726c68@nic.cz>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3UCBuj7kryFn6iI0aR4jzSESZew>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 03 Mar 2017 22:56:21 -0000

On Fri, 3 Mar 2017, Petr Špaček wrote:

> To improve the document I propose:
> - somehow add shortened version of (sometimes implied) advices from 1.2.
> Updating Algorithm Requirement Levels into SHOULD+/SHOULD-/MUST-
> definitions in 2.  Conventions Used in This Document.
>
> Examples I would like to see:
>   SHOULD-   This term means the same as SHOULD.  However, an algorithm
>             marked as SHOULD- may be deprecated to a MAY in a future
>             version of this document. It SHOULD be supported for
>             interoperability reasons.
>             Implementations which give control over used algorithms
>             to user SHOULD NOT use algorithms labeled with "SHOULD-"
>             as default choice. Algorithms with label "MUST" SHOULD
>             [yuck, rephrase this] be preferred.

In the past for ipsec, we have stayed away from telling implementers
what defaults to use. Perhaps this makes a little more sense in the
DNSSEC context, so that's something we should consider.

> Speaking of 3.  Algorithm Selection, I would like to see definitions of
> columns headers "DNSSEC Signing", "DNSSEC Validation", "DNSSEC
> Delegation" and "DNSSEC Validation" again either in 2.  Conventions Used
> in This Document or in text preceding the tables.

Okay.

> Table headers in 3.1.  DNSKEY Algorithms seem somehow clear (signer vs.
> validator) but table 3.2.  DS and CDS Algorithms seems vague to me.
>
> My guesses:
> - "DNSSEC Validation" = usage in configuration file as Trust Anchor

What we mean is "consuming DS/CDS records"

> - "DNSSEC Delegation" = other uses than Trust Anchor in config file

And here we mean "producing DS/CDS records"

> Section 5.  Operational Considerations could emphasise recommendation to
> phase out SHOULD- algorithms in signers and other recommendations for
> MUST- etc. should be added here as well (or the section can be somehow
> merged with 2. Conventions)

The idea is that those terms indicate that already. And Section 5 is
meant to point to potential pitfalls for implementers.

>
> Editorial nits:
> Section 3.1.  DNSKEY Algorithms would be much easier to follow if text
> comments were labeled with algorithm number from the table and ordered
> by number. E.g.:
>
>   1: RSAMD5 is not widely deployed and there is an industry-wide trend
>      to deprecate MD5 usage.

It was not done like that because although in this case we felt we
should describe all table entries, that is not neccesarilly true in
the future. So we did not want to make it an enumerated list. I'll
think about how to increase the readability.

> Let me know if something above is not clear ;-)

I'd be interested if you as an implementer would be willing to follow
these recommendations. And for instance would stop creating new zones
with SHA1, or would stop producing SHA1 based DS records.

Paul