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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
