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

[Petr Špaček <[e-mail]>]

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


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