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

From: Aanchal Malhotra <[email-masked]>
Date: Thu, 3 Aug 2017 17:50:10 +0200

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.

---

From: "Rose, Scott" <[email-masked]>
Date: Thu, 3 Aug 2017 12:17:58 -0400

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). 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

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

===================================
Scott Rose
NIST ITL
[email-masked]
+1-301-975-8439
GV: +1-571-249-3671
===================================

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 3 Aug 2017 18:55:20 +0000

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 <[email-masked]> 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."
> 
> 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.

---

From: Aanchal Malhotra <[email-masked]>
Date: Thu, 3 Aug 2017 21:01:52 +0200

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 <[email-masked]> 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
>
> the network administrator do in the '*Otherwise*' situation from the
> above quote?
>
> +1-301-975-8439 <%28301%29%20975-8439>
> GV: +1-571-249-3671 <%28571%29%20249-3671>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Aug 2017 15:51:12 -0400

On Thu, Aug 3, 2017 at 3:01 PM, Aanchal Malhotra <[email-masked]> wrote:
> 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

>> "In rolling over the KSK, the secure zone may not know which resolvers
>> to give resolver administrators enough time to learn the new KSK."
>>
>> KSK compromise, which would require an emergency KSK rollover, what does the
>> network administrator do in the 'Otherwise' situation from the above quote?
>>
>> 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]

-- 
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

---

From: Aanchal Malhotra <[email-masked]>
Date: Thu, 3 Aug 2017 21:58:04 +0200

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 <[email-masked]>
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.
>
> the network administrator do in the 'Otherwise' situation from the above
> quote?
> >

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 3 Aug 2017 20:06:47 +0000

> On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra <[email-masked]> wrote:
> 
> However, I still don't see how it would help in case of trust anchor/KSK compromise.

This is why I wrote "I don't know if you consider it a solution."

Even so, I think it could be useful, depending on the nature and scale of the zone in question.  For example, if you had to perform an emergency KSK rollover you might do something like email a group of administrators with instructions to manually update their trust anchors.  RFC 8145 would help you know how many administrators followed through on that request.

DW

---

From: Aanchal Malhotra <[email-masked]>
Date: Thu, 3 Aug 2017 22:11:27 +0200

On Thu, Aug 3, 2017 at 10:06 PM, Wessels, Duane <[email-masked]>
wrote:

> compromise.
> Even so, I think it could be useful, depending on the nature and scale of
> the zone in question.  For example, if you had to perform an emergency KSK
> rollover you might do something like email a group of administrators with
> instructions to manually update their trust anchors.  RFC 8145 would help
> you know how many administrators followed through on that request.
>

* "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."*
Sure you are right! But my question was for the "Otherwise" situation.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 3 Aug 2017 16:47:40 -0400

On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
> 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?

The resolver trust point trust anchor set contains both the old and 
pre-published stand-by key.   When the old KSK is compromised, you set 
the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the 
revoked KSK and the standby KSK.   The stand by key does not trace its 
trust through the old key except during the process of being added.   
The attempt to inject the new KSK is foiled by revoking the old KSK and 
publishing the revocation before the hold-down time expires for the 
resolver(s).

At some point - ideally quickly after the old KSK revocation - you 
publish a new standby KSK long enough to inject it as a new trust anchor.

Mike

---

From: Aanchal Malhotra <[email-masked]>
Date: Thu, 3 Aug 2017 23:05:46 +0200

Hi Mike,

On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <[email-masked]>
wrote:

> pre-published stand-by key.   When the old KSK is compromised, you set the
> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked
> KSK and the standby KSK.   The stand by key does not trace its trust
> through the old key except during the process of being added.   The attempt
> to inject the new KSK is foiled by revoking the old KSK and publishing the
> revocation before the hold-down time expires for the resolver(s).
>

I understand and agree to what you say. And even RFC 5011 explicitly states
that this approach works only if there is a backup/standby/pre-published
(whatever name we like) and the assumption that both active and stand-by
keys are not compromised at the same time. The point is again, as Warren
mentioned, that one needs two trust anchors in this case. And the issues
ensue.... Also, I am not sure if there is any implementations that are
actually doing standby-keys (not that I am aware of).

What I am trying to say is that we do not have a solution to this problem
without a back-up key set?

>
> At some point - ideally quickly after the old KSK revocation - you publish
> a new standby KSK long enough to inject it as a new trust anchor.
>
> Mike
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 3 Aug 2017 17:49:35 -0400

I answered the question that you asked.  Other people are weighing in on 
the root and stand by keys.

Mike

On 8/3/2017 5:05 PM, Aanchal Malhotra wrote:
> Hi Mike,
>
> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     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?
>
>     The resolver trust point trust anchor set contains both the old
>     and pre-published stand-by key.   When the old KSK is compromised,
>     you set the revoke bit on the old KSK, and sign the DNSKEY RRSet
>     with both the revoked KSK and the standby KSK.   The stand by key
>     does not trace its trust through the old key except during the
>     process of being added.   The attempt to inject the new KSK is
>     foiled by revoking the old KSK and publishing the revocation
>     before the hold-down time expires for the resolver(s).
>
>
> I understand and agree to what you say. And even RFC 5011 explicitly 
> states that this approach works only if there is a 
> backup/standby/pre-published (whatever name we like) and the 
> assumption that both active and stand-by keys are not compromised at 
> the same time. The point is again, as Warren mentioned, that one needs 
> two trust anchors in this case. And the issues ensue.... Also, I am 
> not sure if there is any implementations that are actually doing 
> standby-keys (not that I am aware of).
>
> What I am trying to say is that we do not have a solution to this 
> problem without a back-up key set?
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
>
>

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 4 Aug 2017 00:11:35 +0200

On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <[email-masked]>
wrote:

> I answered the question that you asked.
>

Yes, thanks Mike. That answers my question about the attack. It was not
clear that pre-published was synonymous with stand-by keys.

> Other people are weighing in on the root and stand by keys.
>
> Mike
>

However, my question  (not just for Mike.)

"If we  have a solution to this (subject of this thread) problem without a
back-up key set? And do we even care about it?" still remains.

Thx.

> backup/standby/pre-published (whatever name we like) and the assumption
> that both active and stand-by keys are not compromised at the same time.
> The point is again, as Warren mentioned, that one needs two trust anchors
> in this case. And the issues ensue.... Also, I am not sure if there is any
> implementations that are actually doing standby-keys (not that I am aware
> of).
>

---

From: Tony Finch <[email-masked]>
Date: Fri, 4 Aug 2017 12:01:47 +0100

> without a back-up key set?

... isn't that true for all kinds of disaster recovery plans?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides: West or northwest, 4 or 5, decreasing 3 at
times. Moderate. Showers, thundery later in Shannon. Good occasionally poor
later in Shannon.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Aug 2017 10:11:41 -0400

> back-up key set? And do we even care about it?" still remains.

Well, we kinda do...

The plan (which I haven't seen, but have been assured exists, is well
fleshed out and documented, etc) is that, if the primary is suspected
to be compromised (or lost), an "emergency key roll" will occur.

This involves, from what I've been told, publishing new keys / hashes
on the IANA site (https://www.iana.org/dnssec/files), and a
"significant press event", publishing the new key on newspapers,
blogs, etc.

The attestations by the trusted community reps and signatures chaining
back to CA certs is supposed to prove the validity of this new key,
and the compromise of the old one.

Unsurprisingly, it would be good if the emergency roll process never
needs to be invoked; the key protections are supposed to be safe
enough that this should be very unlikely. Much of this is very similar
to the loss / compromise of a CA root cert...

W

>>> Which KSK is now the new Trust Anchor  for the resolver?
>>>
>>> KSK and the standby KSK.   The stand by key does not trace its trust through
>>> the old key except during the process of being added.   The attempt to
>>> inject the new KSK is foiled by revoking the old KSK and publishing the
>> backup/standby/pre-published (whatever name we like) and the assumption that
>> both active and stand-by keys are not compromised at the same time. The
>> point is again, as Warren mentioned, that one needs two trust anchors in
>> this case. And the issues ensue.... Also, I am not sure if there is any

---

From: Aanchal Malhotra <[email-masked]>
Date: Fri, 4 Aug 2017 16:43:59 +0200

Thanks Warren.

On Fri, Aug 4, 2017 at 4:11 PM, Warren Kumari <[email-masked]> wrote:

> > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <[email-masked]
> >
> > wrote:
> >>

Wouldn't it be good if this document is accessible to all? Is there a
reason for this document not being public?

> and the compromise of the old one.

That sounds like a plan (with a "significant press event" being my fav part
:))

> to the loss / compromise of a CA root cert...

Yes I agree. It will be a highly unlikely and unfortunate event for the
root trust anchor to be compromised.

But what about emergency key rollover for other islands of trust/security,
if there exist any? And do we care about them?

> KSK).
> the
> through
> that