On Thu, Aug 3, 2017 at 3:01 PM, Aanchal Malhotra <aanch...@bu.edu> wrote: > 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 Trust Anchor for the resolver?
Yeah, 5011 as currently used does very little for emergency rollovers. An attacker who has compromised a key can indeed continue to keep their foothold (or possibly increase it) through the 5011 roll. RFC5011 is only intended for scheduled rollovers, and the old key needs to be revoked "shortly" after the new one is introduced. The timing of all this is, er, subtle - see https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ for some of it... The plan at one point was to have 2 trust anchors, a primary one (being used for signing) and a backup one, which would be published, but not used for signing. If the primary is suspected to be compromised, the backup one can start to be used, and the primary revoked. This would buy some time to figure out what happens next :-P There has been much discussion over the years if this makes things safer or not -- having 2 times as many keys means that a (brute-force) attacker it more likely to be able to factor a key, it is unclear under what scenarios the primary would be compromised while still maintaining trust is the backup, etc.... W > >> >> 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] 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 >> GV: +1-571-249-3671 >> =================================== > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
