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.r...@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.r...@nist.gov > +1-301-975-8439 <%28301%29%20975-8439> > GV: +1-571-249-3671 <%28571%29%20249-3671> > =================================== >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
