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

Petr Špaček <> Fri, 03 March 2017 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2DA51297B8 for <>; Fri, 3 Mar 2017 00:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.021
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m9zN4NMu6rF9 for <>; Fri, 3 Mar 2017 00:49:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C6181297AA for <>; Fri, 3 Mar 2017 00:49:13 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 7D900600D5 for <>; Fri, 3 Mar 2017 09:49:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1488530951; bh=Fw36NH9dqNnLVEj7WURW3+YMrfJxHCgjU14bCdfrR5Y=; h=To:From:Date; b=bkOJDJHpTPUMvT5Aw+fD8f1NN8fKsWmQuybRYSvSsPSe4foZgL1e/WPI5+4ubqI06 GjKPy1ijYSY7a0VsLX88uZ9ttJQgwzAUJ0oUz4kvTmvf894q6Ugc3zkntwoW0ADmrj D2XOsIvAUcmpSaLnRSIHid2AN4ErVwpy/S2k2Tjw=
References: <> <> <> <> <> <> <> <> <>
From: Petr Špaček <>
Organization: CZ.NIC
Message-ID: <>
Date: Fri, 03 Mar 2017 09:49:11 +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: <>
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: <>
Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Mar 2017 08:49:16 -0000

On 2.3.2017 19:00, Paul Wouters wrote:
> On Thu, 2 Mar 2017, Roy Arends wrote:
>> Implementer should follow spec. Spec sez MUST or SHOULD.
> Implementers may decide to implent some algorithms and not some others,
> depending on the level.
>> Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing.
> I understand _you_ find it confusing. It has been used for years in the
> ipsec working group without having caused confusion.
>> Which one should be implemented?
> Saving you the time to re-read Section 1.2 and Section 2:
>    SHOULD+   This term means the same as SHOULD.  However, it is likely
>              that an algorithm marked as SHOULD+ will be promoted at some
>              future time to be a MUST.
>    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.
>    MUST-     This term means the same as MUST.  However, we expect at
>              some point that this algorithm will no longer be a MUST in a
>              future document.  Although its status will be determined at
>              a later time, it is reasonable to expect that if a future
>              revision of a document alters the status of a MUST-
>              algorithm, it will remain at least a SHOULD or a SHOULD-.
> MUST+ is something you made up, but if you have any divine algorithms
> to share, maybe we can do something :P
>> How do I add a grade of importance to specific algorithms, while the
>> protocol itself doesn’t care.
> I don't understand this remark.
> What the + and - symbols are conveying is a likely trend. It is an
> effort to ramp up secure algorithms more quickly and to make the long
> tail shorter. Without being naive and writing in flag days into RFCs
> that implementers are forced to ignore. If we write MUST NOT for SHA1
> one, it would be extremely damaging to the current deployment.
> You indicated you find this useless. That's fine. If the majority of
> the WG agrees with you, we can remove it. I think it will make the
> document less informative to implementers.

Personally I find this +/- notation useful in general but the document
version 02 is hard to follow. I grasped its meaning after reading
conversation in this thread.

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.

And so on. This would convey the important message in much cleaner way
than the looong text in 1.2. I understand that this somehow semantically
duplicates 5.  Operational Considerations but IMHO it is much easier to
follow if definition of the term and reasonably short advices are at one

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.

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
- "DNSSEC Delegation" = other uses than Trust Anchor in config file

Is that right? Why are these two different? It would deserve
clarification in the document.

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)

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.

The very same applies to 3.2.  DS and CDS Algorithms (and it would allow
to get rid of special-case asterisk.)

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

Petr Špaček  @  CZ.NIC