On 09. 02. 22 23:28, Wes Hardaker wrote:
[email protected] writes:
A new version of I-D, draft-ietf-dnsop-nsec3-guidance-03.txt
has been successfully submitted by Wes Hardaker and posted to the
IETF repository.
Name: draft-ietf-dnsop-nsec3-guidance
Revision: 03
Sorry the delay in resolving the discussions in December and getting a
new version out. January was a very long deadline-month for me.
I believe I've acted on all the recent suggestions (thank you!), and the
document is now pretty much ready for WG last call. IMHO.
I'm happy with values mentioned in the document, thank you!
I gave it full re-read and there are two more edit proposals, hopefully
non-controversial:
First, I perceive a "problem" with the current document structure:
2. Recommendation for zone publishers . . . . . . . . . . . . . 3
2.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Salt . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Recommendations for deploying and validating NSEC3 records . 6
3.1. Best-practice for zone publishers . . . . . . . . . . . . 6
3.2. Recommendation for validating resolvers . . . . . . . . . 7
3.3. Recommendation for Primary / Secondary relationships . . 7
It seems odd to have "2. Recommendation for zone publishers" followed by
"3.1 Best-practice for zone publishers".
Either my understanding of relationship between terms "recommendation"
vs. "best practice" is wrong, or these should be somehow renamed. Say
"Background information about NSEC3 parameters" as name of section 2?
Also there is now a SHOULD vs. MUST inconsistency between _content_ of
sections 2.3. Iterations and section 3.1. Best-practice for zone publishers:
2.3. Iterations
...
Although Section 10.3 of [RFC5155] specifies upper bounds for the
number of hash iterations to use, there is no published guidance for
zone owners about good values to select. Because hashing provides
only moderate protection, as shown recently in academic studies of
NSEC3 protected zones [GPUNSEC3][ZONEENUM], this document recommends
that zone owners SHOULD use an iteration value of 0 (zero),
indicating that only the initial hash value should be placed into a
DNS zone's NSEC3 records.
vs.
3.1. Best-practice for zone publishers
First, if the operational or security features of NSEC3 are not
needed, then NSEC SHOULD be used in preference to NSEC3. NSEC3
requires greater computational power (see Appendix B) for both
authoritative servers and validating clients. Specifically, there is
a non trivial complexity in finding matching NSEC3 records to
randomly generated prefixes within a DNS zone. NSEC mitigates this
concern. If NSEC3 must be used, then an iterations count of 0 MUST
be used to alleviate computational burdens. Please note that extra
iteration counts other than 0 increase impact of resource CPU-
exhausting DoS attacks, and also increase risk of interoperability
problems.
My proposal to fix that inconsistency is to remove last part of 2.3,
specifically:
, this document recommends
that zone owners SHOULD use an iteration value of 0 (zero),
indicating that only the initial hash value should be placed into a
DNS zone's NSEC3 records.
and be done with it. Section 3.1 repeats the same thing, so no need to
duplicate it and risk inconsistencies.
The only other thing worth mentioning is a nit which I don't feel
strongly about:
3.2. Recommendation for validating resolvers
Note that a validating resolver MUST still validate the signature
over the NSEC3 record to ensure the iteration count was not altered
since record publication (see [RFC5155] section 10.3).
Technically RRSIG validation is needed only if the resolver treats some
combination of parameters as insecure. If it is going to SERVFAIL for
e.g. large iteration value anyway then there is no point in validating
the RRSIG, I think.
Additionally I've submitted PR#6 with purely editorial nits.
Thank you for your persistence!
--
Petr Špaček @ Internet Systems Consortium
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
