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

Petr Špaček <petr.spacek@nic.cz> Mon, 06 March 2017 08:56 UTC

Return-Path: <petr.spacek@nic.cz>
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 6567812947D for <dnsop@ietfa.amsl.com>; Mon, 6 Mar 2017 00:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.021
X-Spam-Level:
X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 rUWPWmX8FiQe for <dnsop@ietfa.amsl.com>; Mon, 6 Mar 2017 00:56:39 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5386F129479 for <dnsop@ietf.org>; Mon, 6 Mar 2017 00:56:39 -0800 (PST)
Received: from [IPv6:2001:67c:1220:80c:a01b:81f:b724:bdf4] (unknown [IPv6:2001:67c:1220:80c:a01b:81f:b724:bdf4]) by mail.nic.cz (Postfix) with ESMTPSA id 407E360757; Mon, 6 Mar 2017 09:56:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1488790597; bh=GAM2Dd7feZIyiIBS00fRAHa4QepS3/D0jw9ARAPE2jw=; h=To:From:Date; b=RHa2sVcQMs+HKp96CmIhPK7GEDNRCa0gmktBmJLYMjD5n1UmT9hhYpOlT7bKl8hH9 CxJgeChknFS7/gheJ2YmzRhJhwCP07h/VJq+X2du/cEMwt7pQNvC2lfgo9cmQCERBb eeV1kVQuJ/zL9tDAiv7VD71mIm3j4OQnLSjV3/9I=
To: Paul Wouters <paul@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> <alpine.LRH.2.20.1703031747050.13761@bofh.nohats.ca>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <f39fd22b-bbcb-71b6-0cf9-f8e7afd20ba0@nic.cz>
Date: Mon, 6 Mar 2017 09:56:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.20.1703031747050.13761@bofh.nohats.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_aSSIImWufNkgXZRm16nlbWzJtI>
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: Mon, 06 Mar 2017 08:56:42 -0000

On 3.3.2017 23:56, Paul Wouters wrote:
> 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"

Oh, this was totally unclear to me. Please clarify that in 2.
Conventions Used in This Document, or even better re-phase table headers
to make it obvious at the first glance.


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

Understood. Unfortunately it is not that obvious after first read.
Please clarify it either in 2.  Conventions Used in This Document or in
section 5.

I will be happy to re-review potential new versions.


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

I see. IMHO it would be sufficient to prefix the list with a label
indicating that these are only notes. Maybe this?

   Footnotes:
   1: RSAMD5 is not widely deployed and there is an industry-wide trend
      to deprecate MD5 usage.


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

It is important to keep in mind that all of the parameters we are
talking about are user-configurable, so any recommendation will affect
*defaults* which can be overriden by user. I.e. we are not talking about
"stop producing SHA1 based DS records", we can talk about "stop
producing SHA1 based DS records by default".

>From my point of view, having recommendations for interoperable defaults
is very good. Also it lifts burden from implementer as finding good
defaults is a hard thing so I would welcome it.

-- 
Petr Špaček  @  CZ.NIC