I have reviewed draft-mglt-dnsop-dnssec-validator-requirements-04.txt and some comments on the substance of it are below. (I'll also send some grammatical nitpicks via private mail.)
> However, without valid trust anchor(s) and an acceptable value for the > current time, DNSSEC validation cannot be performed. This document lists > the requirements to be addressed so resolvers can have DNSSEC validation > can be always-on. This abstract, and the introduction below, both seem to suggest that the intention of this draft is to list requirements for automatic bootstrapping and recovery of DNSSEC without human intervention. However, several of the requirements actually included in the text describe mechanisms of human intervention: for example, insertion of negative trust anchors or the ability to flush the cache. To my mind, any need for human intervention contradicts the idea of DNSSEC being "always-on"; humans can't react instantly. So I suggest revising the abstract and the problem statement to say that these are requirements for a DNSSEC validator to be recovered when it fails, rather than for it always to be on. > REQ1: Mechanism MUST be provided to update the time of the DNSSEC > Validator. "... or to securely bootstrap the time without the use of DNS." (There's an irritating chicken-and-egg problem when NTP relies on DNS lookups to find clock servers and DNSSEC requires the time to be correct before it can look anything up.) > REQ2: Mechanisms MUST be provided to check the validity of DNSSEC > Validator's Trust Anchors. > > REQ3: Mechanisms MUST be provided to update the Trust Anchor of the > DNSSEC Validator. I would explicitly reference RFC 5011 here, and also Wes Hardaker's 5011 security considerations draft, and IANA's publication of trust anchors via HTTPS. > This situation should not happen as when a ZSK is renewed all RRsets > validated by the old ZSK are flushed from the cache. I think maybe you meant "rolled", not "renewed"? I wouldn't say old RRsets will be "flushed" from the cache when a key is rolled -- that suggests that they're being removed en masse, prior to expiry, as a result of the key rollover. But if the rollover has been carried out correctly, with the old ZSK published in the DNSKEY RRset for at least as long as the longest TTL in the zone after the new ZSK started signing, then all the cached RRSIGs will be *expired* from the cache by the time the old key is removed. If the key rollover is done incorrectly, then a mechanism will be needed to flush the entire validator cache, or to flush the namespace below the problematic DNSKEY. I would reference RFC 7583 here. > This DS RRset can be invalid because its RDATA (KSK) is not anymore > used in the child zone or because the DS is badly signed and cannot be > validated by the DNSSEC Validator. > > In both cases the child zone is considered as insecure and the valid > child zone's KSK should become a Trust Anchor KSK. I don't think this is correct. The child zone would be treated as bogus, not insecure, and would return SERVFAIL. (IIRC, it would only be treated as insecure if the DS RRset exclusively referenced DNSKEY algorithms not supported by the validator.) In any case, this doesn't strike me as a DNSSEC failure, but as DNSSEC working correctly to prevent an attack. The ability to configure trust anchors at arbitrary points in the tree is a useful requirement to specify, though. > REQ7: Mechanisms MUST be provides to informed the DNSSEC Validator that > a KSK or a ZSK MUST NOT be used for RRSIG validation. Unlike "flushing", > "MUST NOT be used" means the issue is not a synchronization issue, but > that legitimate keys are invalid. Such Keys are known as Negative Trust > Anchors [I-D.livingood-negative-trust-anchors]. Negative trust anchors are now specified in RFC 7646. This isn't a very clear description of them; I'll suggest revised text in separate mail. > REQ9: Mechanisms MUST be provided to inform the DNSSEC Validator a KSK > or a ZSK is to be used for private use. I'm not sure how this differs from REQ6? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
