On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new T/rust Anchor /for the resolver?
The resolver trust point trust anchor set contains both the old and pre-published stand-by key. When the old KSK is compromised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK. The stand by key does not trace its trust through the old key except during the process of being added. The attempt to inject the new KSK is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s).
At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor.
Mike
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
