Automated Updates of DNS Security (DNSSEC) Trust Anchors
also
- std-74
Extracted elements (24)
A DNSKEY with the REVOKE bit set has a different fingerprint than the same key without the bit set, which affects matching against DS records in the parent zone or fingerprints stored at resolvers for trust point configuration.
Revocation requires knowledge of the private key of the DNSKEY being revoked (self-signed RRSet). This prevents a compromised key B from revoking a co-existing key A by simply omitting it from a signed RRSet, since B cannot produce a self-signed revocation for A.
The add hold-down timer mitigates but does not completely eliminate the attack where a compromised key adds a new malicious trust anchor. A determined attacker holding one compromised key could keep a single resolver from seeing revocation by intercepting real data and substituting their own signed responses — the protocol acknowledges this residual risk is no worse than the pre-existing compromised-key situation.
The mechanism provides protection against N-1 key compromises among N keys at a trust point. If all trust-anchor keys at a trust point are simultaneously compromised, a manual or out-of-band update of all resolvers is required; automated recovery is not possible in that scenario.
Setting the REVOKE bit on a DNSKEY changes its fingerprint relative to a non-revoked version of the same key, which affects matching against DS records in the parent zone (per RFC 3755) and against fingerprints stored at resolvers for trust point configuration. Operators must account for this during revocation procedures.
A compliant resolver MUST be able to manage at least five SEP keys per trust point.
A key in the Revoked state MUST permanently be considered invalid as a trust anchor. A key in the Removed state MUST NOT be considered a valid trust anchor.
A resolver configured for automatic trust anchor update MUST query the trust point no less often than the lesser of 15 days, half the original DNSKEY RRSet TTL, or half the RRSIG expiration interval, and no more often than once per hour: queryInterval = MAX(1 hr, MIN(15 days, 1/2*OrigTTL, 1/2*RRSigExpirationInterval)).
A resolver MUST NOT treat a new SEP key as a trust anchor until the add hold-down time (30 days or the original TTL expiration, whichever is greater) has expired AND the resolver has retrieved and validated a DNSKEY RRSet after hold-down that still contains the new key.
If a validated DNSKEY RRSet is seen and a key that was previously accepted as Valid is absent from that RRSet, a 'KeyRem' event is triggered, moving the key to the Missing state. The DNSKEY RRSet does not need to be continuously present, but when it is seen and validated, the key MUST be present or else KeyRem fires.
If the active refresh query fails, the resolver MUST repeat the query no more often than once an hour and no less often than the lesser of 1 day, 10% of the original TTL, or 10% of the original expiration interval: retryTime = MAX(1 hour, MIN(1 day, 0.1*origTTL, 0.1*expireInterval)).
Once a resolver has accepted a key as a trust anchor, the key MUST be considered a valid trust anchor by that resolver until explicitly revoked via the REVOKE bit mechanism.
Once a resolver sees a DNSKEY with the REVOKE bit set in a self-signed RRSet, the resolver MUST NOT use that key as a trust anchor or for any other purpose except to validate the RRSIG over the DNSKEY RRSet for the purpose of validating the revocation itself. Revocation is immediate and permanent.
A trust point is considered deleted when all of its trust anchors are revoked. If no superior trust point exists, data at and below the deleted trust point is considered insecure. A subordinate trust point that validly chains to a superior trust point MAY be deleted by a resolver after 180 days.
The add hold-down time is 30 days or the expiration time of the original TTL of the first trust point DNSKEY RRSet containing the new key, whichever is greater. This ensures at least two validated DNSKEY RRSets containing the new key are seen before acceptance.
The AddPend state represents a key that has been seen at the resolver with its SEP bit set and included in a validated DNSKEY RRSet, but is still within the hold-down period. The resolver tracks which keys originally validated the RRSet; if all those keys are revoked before hold-down expires, the acceptance process is aborted.
The Missing state is abnormal: the key remains a valid trust-point key but was not seen in the last validated DNSKEY RRSet. Zone operators should use the REVOKE bit before removal rather than simply omitting the key.
The remove hold-down time is 30 days, after which information about a revoked key may be purged from the resolver's database. This is a key management bookkeeping parameter; failure to remove it does not impact security.
IANA assigned bit 8 of the DNSKEY Flags field (as defined in Section 7 of RFC 4034) as the REVOKE flag for the automated trust anchor update mechanism.
Allowing a resolver to update its trust anchor set based on in-band key information is potentially less secure than a manual process. However, given the scale of DNS resolvers requiring update upon key compromise and the lack of a standard DNS management framework, this approach is deemed no worse than the existing situation.
Recovery from key compromise is possible as long as at least one valid trust-anchor key remains uncompromised. Zone owners should determine their acceptable number of valid trust anchors and be prepared to implement recovery procedures upon detecting a compromise.
While the zone owner creates and distributes keys, it is wholly the resolver owner's decision whether to accept those keys. Resolver owners and implementers MAY choose to permit or prevent automated key status updates for specific trust points; if they prevent automated updates, they must establish manual or out-of-band mechanisms.
A trust-point key transitions through six states at the resolver: Start (not yet a trust anchor), AddPend (seen with SEP bit, hold-down timer running), Valid (accepted trust anchor), Missing (valid but absent from last RRSet), Revoked (REVOKE bit seen with self-signed RRSet), and Removed (purged after remove hold-down). Transitions are triggered by events: NewKey, KeyPres, KeyRem, AddTime, RemTime, and RevBit.
Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. When set to '1' and a corresponding RRSIG(DNSKEY) signed by that key is present, the resolver MUST consider the key permanently invalid for all purposes except validating the revocation.