I don't have a strong reason for opposing the proposal, but, frankly, the need for this wasn't clear to me just by reading the draft. I see the potential problems with evil parents, but the draft didn't convince me that it's an important and critical enough to justify a new protocol extension (which made me recall the camel discussion), not least because if the parent is malicious in the DNS then all bets are off already. If there's actually a consensus that this is an important problem to solve, I wouldn't challenge that. But it would help newer/future readers if this doc explains the need more specifically and in more detail.
It's also not clear how effective this is against the evil parent tweaking the delegation (changing NS, e.g). The draft seems to try to address this point in a few places: [...] However, both of these actions cannot be hidden, thus exposing such malicious behavior when combined with public transparency logs. [...] Replacing the NS and DS records of a child zone can still be done in a targetted attack mode, but these events are something that can be easilly tracked by a transparency infrastructure similar to what is now in use for the WebPKI using [RFC6962](bis). but I was not sure why we can't also do this for the "deep link state" problem (replacing a delegation with a parent's authoritative record). That's probably because I don't know much about the tracking "by a transparency infrastructure". In that case it might help if it explains it in more detail. I have a few more specific comments: - I'd suggest making the requirement to validator implementations more explicitly: [...] if any such signed data is encountered by validating resolvers, that this data should be interpreted as BOGUS. Probably in a separate section like "Validator Behavior" rather than in Introduction, and maybe with an RFC2119 keyword. - Section 3 [...] For example, the DNSSEC root key could ignore the NS records for ".org" and "example.org" and could place a record "www.example.org" directly into its own zone, with a "the DNSSEC root key could ignore..." doesn't make much sense to me. Does this perhaps mean "the root zone could ignore..."? - Section 4 hierarchy. This commits a parent in the DNS hierarchy to only sign NS and DS records (i.e. all non-glue, delegation records) for its child zones. Should this be "NSEC(3) and DS records"? -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
