On 11/1/17, 08:17, "DNSOP on behalf of Patrik Wallstrom" <dnsop-boun...@ietf.org on behalf of pa...@blipp.com> wrote:
> If I remember the discussions correctly, there was a sense that the > resolver decides the local policy. And that yes, those are the three > options. Perhaps the options should be made more clear in a text somewhere. The reason why I'm digging into this is that "things change." Back about 15-20 years ago, when the design work was done, the original workshopping, documentation and re-documentation that led to the current RFCs on DNSSEC (numbering 4033-4035), the concerns were a bit different than perhaps they are now that we have operational experience. Local policy is and remains the overriding philosophy of validation. It is purely up to the receiver to determine what they trust. But there's also the operational reality that most users will unbox a tool and rely on default settings until they realize they are unhappy with it and realize how to tweak it. Besides local policy, the principle that plays a role here is maintaining as much robustness as possible. Robustness means - getting answers to user's questions if at all possible. DNSSEC, as an example of "slapped on security" (over an existing system, will inherently cause some once valid states to be invalid, for reasons based on "security." To counter act that (not eliminate it), being conservative on what to block (SERVFAIL) was thought to be a design goal. The desire to maximize robustness is something that might be subject to "things change." During the time of design, there wasn't a mature registration economy (registries, DNS hosting, registrars, etc.), little thought was given to malicious mis-dealings in delegations. I'm thinking in this direction based on a statement that "perfering a local trusted key over the DS record" is "the only way to go" because a "parent could steal a zone." Perhaps what is needed is to examine the situation when it is found that there is a conflict between a trust anchor rooted-chain and a chain that passes up through a DS record on to an upper trust anchor. (Keeping in the back of the mind that a resolver is allowed, via local policy, to build any kind of chain it wants, not just a chain that matches the delegation tree.) 1 - What if a higher-level trust anchor and chain validates an RR set but no trust anchor and chain is possible? I.e., TA(example)->DS(delegation.example)->KEY (delegation.example)->www.delegation.example/IN/NULL validates but TA (delegation.example)->nothing->www.delegation.example/IN/NULL By "nothing" I mean there's no key matching that cited in any RRSIG(NULL) over www.delegation.example/IN/NULL. In a benign world, this should work as it is possible that the trust anchor base is outdated. Perhaps there was a re-delegation, perhaps a misconfiguration. In a malignant world, this would result from a "corrupted" registry. (Where corrupted means, not playing by the rules whether intentionally or not.) 2 - The opposite, the trust anchor validates, not the DS chain This could happen with a child forgetting to tell the parent that they've changed secure entry points, (been there, got a t-shirt and had a cool packet dump to analyze) but also had some population of trust anchor managers playing along. The latter group didn't have errors, the non-players did experience SERVFAILs. 3 - they both work or both fail I don't see an issue. What I'm coming to is ... if there's a choice between being afraid of a malicious registry or being afraid of operational errors, for reasons I don't think are made in this email, I'm still opting to be afraid of operational errors because, well, them I've seen. Are there cases of "corrupted" registries make the threat of "stolen zones" a real thing?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
