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

[Paul Wouters <[e-mail]>]

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