Re: [DNSOP] [Ext] Re: Resolver behaviour with multiple trust anchors

[Edward Lewis <[e-mail]>]

On 10/31/17, 15:52, "DNSOP on behalf of Paul Wouters" <[e-mail] on behalf of [e-mail]> wrote:
>this zone can never be stolen from me by a parent.
    
Can you elaborate on this, what do you mean "stolen" by a parent?

The reason I am asking - choosing one strategy (any key, configured key rules, DS rules) is based on what one most wants to solve.  For "robustness" in the sense of most aggressively getting an answer, opting to accept any (and I'll use the word:) approved key is going to lead to more answers being validated.  "More answers" may or may not be a good thing, but the fact is that numerically, having more trusted points from which to build chains will lead to more validated answer sets.

By "approved" I mean any key that has passed muster to be a trusted key in the resolver and/or there is a chain of trust from the key set back to another trusted key.  Please don't take this as a general definition, I'm using it only within the context of this mail message and only within the confines of the protocol's technical work, not any judgement regarding legitimacy in operations.

Back to the question above, to help enumerate the scenarios in which one would opt to not trust a key that has been learned via a chain of trust in the face of a trusted key, it would help to understand what is meant by a parent "stealing" a zone.

What I am thinking is:

(Un- cut point/DS set is removed, re- cut point/DS set is changed.)

01 A child may be un-delegated by operational error at the parent.
02 A child may be un-delegated in accordance with the registration agreement.
03 A child may be un-delegated outside of the registration agreement.

04 A child may be re-delegated by operational error at the parent.
05 A child may be re-delegated in accordance with the registration agreement.
06 A child may be re-delegated outside of the registration agreement.

07 A child may be un-DSd by operational error at the parent.
08 A child may be un-DSd in accordance with the registration agreement.
09 A child may be un-DSd outside of the registration agreement.

10 A child may be re-DSd by operational error at the parent.
11 A child may be re-DSd in accordance with the registration agreement.
12 A child may be re-DSd outside of the registration agreement.

Before getting into the "why's", the impacts of cases:

01-03: Answers for the zone's data will be NXDOMAIN (once TTLs expire)
04-06: Answers will come from a different administrative authority
05-09: Answers will be accepted as Insecure unless the trust anchor is configured
10-12: Answers signed by other keys may be received

Cutting along the why's:

01,04,07,10 (Operator error) - The underlying DNS service error must be fixed, in the meantime, flexibility is desired to prevent service disruption.

02,05,08,11 (Justified change) - The issue lies above the level of DNSSEC.  By "justified change", this includes term expiration, lack of payment, failing to abide by acceptable use policy, etc.  Beyond the scope of the technology, this might even come as a result of a court order, to name a reason for this category.  In this case, the parent exerts the protocol prerogative of where it delegates names to enforce whatever policy governs.

03,06,09,12 (Unjustified change) - This would include any reason that could be seen as "corruption" of the registry operator role.  I would include all cases of "stolen" to be here, lacking a better definition of "stolen."

A dimension I haven't included is whether a validator has a trust anchor for the name in question or not.  (If not, then the issue of the conflict doesn't matter.)

The next step here is to look at the relative frequency of each case.  Mind, I'm not including child operator error in any of this (which would expand the cases).

The reason for drilling into this is the assertion that trusting configured trusted keys over the DS record is "the only workable solution".  I'm not convinced, I think that the cases in which that is the preferred option is in the minority of the failure modes.

What's in the back of my mind is that ultimately, there's still the DNS problem - the parent unilaterally controls the existence and direction of the delegation.  DNSSEC can't overcome that.  DNSSEC can only choose to be more restrictive (and thus brittle in some sense) or be as lenient as possible (for robustness in the sense of getting an answer to the query).