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 -- each@isc.org
Internet Systems Consortium, Inc.