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

I answered the question that you asked.  Other people are weighing in on 
the root and stand by keys.

Mike

On 8/3/2017 5:05 PM, Aanchal Malhotra wrote:
> Hi Mike,
>
> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns 
> <msj@nthpermutation.com <mailto: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 <mailto:DNSOP@ietf.org>
>     https://www.ietf.org/mailman/listinfo/dnsop
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>