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