Also see thread starting at:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
Ed was the last to comment on Olaf:
> >
> >>
> >> #4.3.1 KSK Compromise
> >> #
> >> # When the KSK has been compromised the parent must be notified as soon
> >> # as possible using secure means. The key set of the zone should be
> >> # resigned as soon as possible. Care must be taken to not break the
> >> # authentication chain. The local zone can only be resigned with the
> >> # new KSK after the parent's zone has created and reloaded its zone
> >> # with the DS created from the new KSK. Before this update takes place
> >> # it would be best to drop the security status of a zone all together:
> >> # the parent removes the DS of the child at the next zone update.
> >> # After that the child can be made secure again.
> >>
> >> During any emergency impacting a system, I don't expect the system to
> >> continue operating smoothly. As here, if there is a compromised key,
> >> I don't expect maintaining the authentication chain is a priority. Two
> >> things might be reasonable - dropping security and publication of the
> >> problem via other channels.
> >>
> >> Minimizing an outage is a priority of course, meaning that one key ought
> >> not cause disruption for sibling domains.
> >>
> >> #
> >> # An additional danger of a key compromise is that the compromised key
> >> # can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
> >> # rollover at the parent. When that happens the domain can be in
> >> # dispute. An authenticated out of band and secure notify mechanism to
> >> # contact a parent is needed in this case.
> >>
> >> It's never wise to secure a system only by using the system's security.
> >
> >We already suggested alternative text please see:
> >http://darkwing.uoregon.edu/~llynch/dnsop/msg03461.html
> >
> >I hope that text is clearer.
>
>
> What I don't understand is how the "chain of trust is broken."
>
> It's the resolver that evaluates the trustworthiness of an RRSet,
> it's not set by the server. Hence, with the potential that someone
> is maliciously publishing data via a compromised key, the honest
> server can't break the chain of trust.
>
The point we are trying to make is that the zone administrator has the
option to stop using the compromised key while there are still
signatures made with that key somewhere in the DNS.
The first reaction may be I will immediatly stop using the compromised key
and start using another one. The cost of this action is that the zone may
be considered bad by a lot of resolvers that receive bonafide data.
> All the server can do is limit the exposure caused by the key and the
> fallout of the problem.
>
> First, using the private key must stop and the (if KSK) DR RR no
> longer be signed by the parent. The latter begins to limit the
> duration of the vulnerability.
>
> You don't gain by pulling the key or DS RR before the latest
> expiration of a legitimate key or DS because the attacker could be
> using that in a replay tactic. The benefit of this is that you don't
> "break" legitimate data still in caches.
>
> However, overriding all of this, is the fact that until the latest
> expiring copy of the key or DS expires, you do not have security
> control of the zone. The big question is - how long is a zone admin
> willing to allow this window of vulnerability?
>
> Pulling data early doesn't effectively shorten this window.
I think we try to say the same thing. Please have a look at the new text that
we proposed.
I pulled the newly proposed text from
http://darkwing.uoregon.edu/~llynch/dnsop/msg03461.html
There are now new comments below.
--Olaf
----------start new text----------------------------
4.3 Planning for Emergency Key Rollover
This section deals with preparation for a possible key compromise.
Our advice is to have a documented procedure ready for when a key
compromise is suspected or confirmed.
When the private material of one of your keys is compromised it can
be used for as long as a valid trust chain exists. An trust chain
remains intact for:
o as long as a signature over the compromised key in the trust chain
is valid,
o as long as a parental DS RR (and signature) points to the
compromised key,
o as long as the key is anchored in a resolver and is used as a
starting point for validation. (This is generally the hardest to
update.)
While an trust chain to your compromised key exists, your name-space
is vulnerable to abuse by anyone who has obtained illegitimate
possession of the key. Zone operators have to make a trade off if
the abuse of the compromised key is worse than having data in caches
that cannot be validated. If the zone operator chooses to break the
trust chain to the compromised key, data in caches signed with this
key cannot be validated. However, if the zone administrator chooses
to take the path of a regular roll-over, the malicious key holder can
spoof data so that it appears to be valid.
4.3.1 KSK Compromise
A zone containing a DNSKEY RRset with a compromised KSK is vulnerable
as long as the compromised KSK is configured as trust anchor or a
parental DS points to it.
A compromised KSK can be used to sign the keyset of an attackers
zone. That zone could be used to poison the DNS.
Therefore when the KSK has been compromised, the trust anchor, or the
parental DS, should be replaced as soon as possible. It is local
policy whether to break the trust chain during the emergency
rollover. The trust chain would be broken when the compromised KSK
is removed from the child's zone while the parent still has a DS
pointing to the compromised KSK. (The assumption is that there is
only one DS at the parent if there are multiple DSs this does not
apply -- however the chain of trust of this particular key is
broken).
Note that an attacker's zone still uses the compromised KSK and the
presence of a parental DS would cause the data in the this zone to
appear as valid. Removing the compromised key would cause the
attacker's zone to apear as valid and the child's zone as bogus.
Therefore we advise not to remove the KSK before the parent has a DS
to a new KSK in place.
4.3.1.1 Keeping the Chain of Trust Intact
If we follow this advice the timing of the replacement of the KSK is
somewhat critical. The goal is to remove the compromised KSK as soon
as the new DS RR is available at the parent. And also make sure that
the signature made with a new KSK over the key set with the
compromised KSK in it expires just after the new DS appears at the
parent. Thus removing the old cruft in one swoop.
The procedure is as follows:
1. Introduce a new KSK into the key set, keep the compromised KSK in
the key set.
2. Sign the key set, with a short validity interval. The validate
interval should expire shortly after the DS is expected to appear
in the parent and the old DSs have expired from caches.
3. Upload the DS for this new key to the parent.
4. Follow the procedure of the regular KSK rollover: Wait for the DS
to appear in the authoritative servers and then wait as long as
the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRset
and modify/extend the expiration time.
5. When the new DS has appeared, remove the compromised DNSKEY RR
from the zone and re-sign the key set using your "normal"
validity interval.
An additional danger of a key compromise is that the compromised key
could be used to facilitate a legitimate DNSKEY/DS rollover and/or
nameserver changes at the parent. When that happens the domain may
be in dispute. An authenticated out of band and secure notify
mechanism to contact a parent is needed in this case.
4.3.1.2 Breaking the Chain of Trust
There are two methods to break the chain of trust. The first method
causes the child zone to appear as 'bogus' to validating resolvers.
The other causes the the child zone to appear as 'insecure'. These
are described below.
The child zone replaces the current KSK with a new one and resigns
the key set. Next it sends the DS of the new key to the parent.
Only after the parent has placed the new DS in the zone, the child's
chain of trust is repaired.
An alternative method of breaking the chain of trust is by removing
the DS RRs from the parent zone altogether. As a result the child
zone would become insecure.
4.3.2 ZSK Compromise
Primarily because there is no parental interaction required when a
ZSK is compromised, the situation is less severe than with a KSK
compromise. The zone must still be re-signed with a new ZSK as soon
as possible. As this is a local operation and requires no
communication between the parent and child this can be achieved
fairly quickly. However, one has to take into account that just as
with a normal rollover the immediate disappearance of the old
compromised key may lead to verification problems. The pre-
publication scheme as discussed above (Section Section 4.2.1.1)
minimizes such problems.
4.3.3 Compromises of Keys Anchored in Resolvers
A key can also be pre-configured in resolvers. For instance, if
DNSSEC is successfully deployed the root key may be pre-configured in
most security aware resolvers.
If trust-anchor keys are compromised, the resolvers using these keys
should be notified of this fact. Zone administrators may consider
setting up a mailing list to communicate the fact that a SEP key is
about to be rolled over. This communication will of course need to
be authenticated e.g. by using digital signatures.
End-users faced with the task of updating an anchored key should
always validate the new key. New keys should be authenticated out of
the DNS, for example, looking them up on an SSL secured announcement
website.
----------end new text----------------------------
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
