Hi Duane, Thanks for pointing to RFC 8145. It's a very nice mechanism to allow zone administrators to know the status of key rollover in the DNSSEC signed zone to take further decisions.
However, I still don't see how it would help in case of trust anchor/KSK compromise. With RFC 8145, the zone administrator would know that the resolvers are using old (now compromised) trust anchor/KSK for validating the data. But there is no way for them to roll-over this trust anchor/KSK in an authentic way. In other words, this RFC might help in detecting the problem (when a resolver signals a key that is not the zone's trust anchor). But I don't see anything in the RFC that says what a zone administrator can do in such a case. Am I missing something? Thx, Aanchal Malhotra. On Thu, Aug 3, 2017 at 8:55 PM, Wessels, Duane <dwess...@verisign.com> wrote: > Hello Aanchal, > > I don't know if you consider this a solution, but you may want to take a > look at RFC 8145, aka "Signaling Trust Anchor Knowledge." > > Per this RFC, validators can convey trust anchor contents to zone > operators via periodic queries. By looking at the signal data you can see > how many (and which) validators have old versus new keys. > > It is implemented in recent versions of BIND and Unbound. > > DW > > > > > On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra <aanch...@bu.edu> 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 > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
