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

Hi Scott,

Thanks for the response. I have another question in that case. Please see
below.

On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott <scott.rose@nist.gov> wrote:

> Hi,
>
> (800-81 author here)
>
> That needs to be updated as it was from the earlier revision of 800-81. It
> really should stress the use of RFC 5011 automated trust anchor update
> process. The first version of the doc assumed RFC 5011 was not available in
> the majority of implementations, which is not the case now. I’d probably
> update that to recommend (and stress) to always use the RFC 5011 rollover
> process.
>
> As for emergency rollovers, some admins do worry about it and plan for it
> by having a pre-published KSK in the DNSKEY RRset at all times (not just
> during an actual rollover process). RFC 5011 can be used there too (see the
> “Scenarios” section in RFC 5011).
>
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?

> There isn’t a single doc that focuses on KSK rollovers, but it is
> discussed in the BCP docs like RFC 6781 and other implementation-specific
> documents.
>
> Scott
>
> On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote:
>
> Dear all,
>
> May be this has been discussed long ago on the list or elsewhere. Please
> guide me to proper pointers, if any.
>
> Section 11.2.1 in [1]
> <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf>
> states the following for KSK rollover for *locally secure zones*:
>
> "*In rolling over the KSK, the secure zone may not know which resolvers
> have stored the public key as a trust anchor. If the network administrator
> has an out-of-band method of contacting resolver administrators that have
> stored the public key as a trust anchor (such as e-mail), the network
> administrator should send out appropriate warnings and set up a trusted
> means of disseminating the new trust anchor. Otherwise, the DNS
> administrator can do nothing except pre-publish the new KSK with ample time
> to give resolver administrators enough time to learn the new KSK.*"
>
> I have the following questions:
>
> a) This might work in case of an active KSK rollover. However in case of
> KSK compromise, which would require an emergency KSK rollover, what does
> the network administrator do in the '*Otherwise*' situation from the
> above quote?
>
> b) I am just curious to know if this is even an issue or do network
> administrators care about it? And if it is, Is there any RFC or relevant
> doc or mailing list that discusses this problem/solutions, etc.?
>
> References:
> [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
> NIST.SP.800-81-2.pdf
>
> Thanks,
> Aanchal Malhotra.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> ===================================
> Scott Rose
> NIST ITL
> scott.rose@nist.gov
> +1-301-975-8439 <%28301%29%20975-8439>
> GV: +1-571-249-3671 <%28571%29%20249-3671>
> ===================================
>