On 26. 02. 22 0:40, Wes Hardaker wrote:
Petr Špaček <[email protected]> writes:
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".
You bring up a good point. When looking at it though, 3.1 really does
look written for zone publishers but actually maybe we should change the
title of 2 is actually what's wrong. How about "NSEC3 parameter value
considerations":
2. NSEC3 parameter value considerations . . . . . . . . . . . . 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 . 5
3.1. Best-practice for zone publishers . . . . . . . . . . . . 6
3.2. Recommendation for validating resolvers . . . . . . . . . 6
3.3. Recommendation for Primary / Secondary relationships . . 7
Sounds good to me.
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:
Good catch; I took your suggestion about dropping that half-sentence.
Okay, that clarifies things. Thank you!
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.
I think the reason is the error is different (eg EDE). You're right
that the processing may be an overload (but if it is, you can always
just drop it per the other thread too). Anyway, if others support this
change we can discuss it further, but it's been discussed before. So to
the others: please chime in if you agree and we want to revert the
existing consensus based on this new thinking.
Maybe there is an option to keep the current MUST if we add an
additional clarification?
Keep this:
>>> 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).
And here add this as continuation of the previous sentence?
... because the invalid signature might have additional implications.
E.g. EDE code, or insecure validation status if an implementation chose
to treat certain range of NSEC3 iteration values as DNSSEC-insecure etc.
(modulo grammar fixes etc., of course)
I think this makes the reason clear to everyone and also makes it
somewhat legal to ignore signature validation it IF "visible outcome"
does not change by doing so.
What do you think?
--
Petr Špaček
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
