On 31 Oct 2017, at 12:23, Michael StJohns wrote:
But sadly - the language in RFC6840 section 5.10 is controlling...
basically, any implementation can do whatever it wants.
A DNSSEC validator may be configured such that, for a given response,
more than one trust anchor could be used to validate the chain of
trust to the response zone. For example, imagine a validator
configured with trust anchors for "example." and "zone.example."
When the validator is asked to validate a response to
"www.sub.zone.example.", either trust anchor could apply.
When presented with this situation, DNSSEC validators have a choice
of which trust anchor(s) to use. Which to use is a matter of
implementation choice. Appendix C discusses several possible
algorithms.
And the two paragraphs that follow those give more guidance:
It is possible and advisable to expose the choice of policy as a
configuration option. As a default, it is suggested that validators
implement the "Accept Any Success" policy described in Appendix C.2
while exposing other policies as configuration options.
The "Accept Any Success" policy is to try all applicable trust
anchors until one gives a validation result of Secure, in which case
the final validation result is Secure. If and only if all
applicable
trust anchors give a result of Insecure, the final validation result
is Insecure. If one or more trust anchors lead to a Bogus result
and
there is no Secure result, then the final validation result is
Bogus.
And once again we see the folly of the words "implementation choice"
when trying to come up with a coherent DNS.
The full quote makes the situation murkier: it is a combination of
implementation choice plus configuration options. Some folks on this
list strongly prefer that, others strongly don't.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
