On 11/6/17, 10:57, "DNSOP on behalf of Petr Špaček" <dnsop-boun...@ietf.org on behalf of petr.spa...@nic.cz> wrote:
>I did my best to explain my reasoning, let me know if you can see some holes >in the reasoning. Coming from my assumption that "use any chain" is the best way to go, I tried to figure out why you are coming to a different conclusion. There are two "holes" I see. One is that DNSSEC's design is centered on preventing a receiver from accepting forged data. Two is that the design of DNSSEC has to take into account the limitations of the base (DNS) protocol. >From the point of view of a validator (operator), it is your choice to decide >what to trust, or not. You may decide that a certain signed zone is critical >to your operations, so you get the DNSKEY with the SEP bit set and pin it as >trusted. How do you know whether the zone manages its keys in accordance with >Automated Updates of DNSSEC Trust Anchors? How do you know when to update the >trust anchor, especially if the zone is not running in accord with Automated >Updates? The DNS protocol doesn't let you know. You could find this via out-of-band channels, like via something at a URL (listing the secure entry points), via direct communication with the zone operators. The protocol (DNS) lacks per-zone signaling. For that reason, the assumptions of how DNSSEC is set up assumes a unified one-protocol set up. E.g., even in the early days, .COM was an unusual case and we were tempted to define DNSSEC to act differently for it or other large delegated zones. It took a while to get "opt-out" into the protocol in a way anyone could make use of it, which was a central issue. (The history of that is murkier than I may be presenting.) We even tried to have different key "strengths." That failed to materialize as we realized the weakest link is still the weakest link. Trying to differentiate zones by "criticality" begins walking a thread of deciding "what is critical" and how does one decide that? (There are TLD operators who told me "it's okay, we think of this TLD as experimental." To me a TLD would be critical, but that view is apparently not universally shared.) How would a validator determine, objectively, whether a zone is critical to the validator's audience? Once it did determine, how would it know what the security policy was of the zone (does it honor the add hold-down time, etc., does it even separate the KSK from the ZSK, would it switch to a CSK, and so on). I could see a knob for a validator operator to select zones for pinning the trust anchors, for selecting them for STD 69 (Automated Update) treatment. I can't see though having a restrictive policy (if trust anchor, no DS - so to speak) be the default as that would be the unusual case (having a trust anchor). DNSSEC never assumed that the whole tree would be signed. That is why trust anchors were invented. DNSSEC, at first, even tried to allow an arbitrary policy of "who can sign what." (That is why there's "Domain Name System Security Extensions" from March 1999 and then "Domain Name System Security (DNSSEC) Signing Authority' from November 2000. That's RFC 2535 and 3008 for those that speak RFC numbers. DNSSEC didn't adopt the on-tree signing authority until we exhausted attempts at something more liberal.) The problem with arbitrary policies is that, first, you must be able to write them down. This is why the guidance in "Protocol Modifications for the DNS Security Extensions" leads to "any" chain. "Clarifications and Implementation Notes for DNS Security (DNSSEC)" opens the possibility that knobs can be included, which is the prerogative of the implementer to build and the operator to use (local policy). I see these two documents as compatible. The bottom line is that one can choose to abide by a rule of "if a trust anchor is there, ignore other chains" but recall that the choice is made by the validator operator, not the zone administrator, as the validator operator is also responsible for keeping the trust anchors current and accurate, it is their own failure if that is not the case, and they exclusively have the ability to fix a conflict. The bottom line is that the zone administrator doesn't get a say - it's all up to the validator operators.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
