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

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 <dwessels@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 <aanchal4@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
>
>