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

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

> I answered the question that you asked.
>

Yes, thanks Mike. That answers my question about the attack. It was not
clear that pre-published was synonymous with stand-by keys.

> Other people are weighing in on the root and stand by keys.
>
> Mike
>

However, my question  (not just for Mike.)

"If we  have a solution to this (subject of this thread) problem without a
back-up key set? And do we even care about it?" still remains.

Thx.

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