Re: [DNSOP] Emergency KSK Rollover for locally secure zones.

Hi Mike,

On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <msj@nthpermutation.com>
wrote:

> 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).
>

I understand and agree to what you say. And even RFC 5011 explicitly states
that this approach works only if there is a backup/standby/pre-published
(whatever name we like) and the assumption that both active and stand-by
keys are not compromised at the same time. The point is again, as Warren
mentioned, that one needs two trust anchors in this case. And the issues
ensue.... Also, I am not sure if there is any implementations that are
actually doing standby-keys (not that I am aware of).

What I am trying to say is that we do not have a solution to this problem
without a back-up key set?

>
> 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
>
>