Dear Colleagues,
After the WGLC terminated we were informed that we had overlooked some
comments about section 4.3. We looked at this again last week and
choose to rewrite the section with the intend to provide more clarity
and fix the mistakes in the original text.
The modified text is below. Unless there are comments on this text we
will publish a new version of the document next week.
Olaf & Miek.
---- Proposed 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
Kolkman & Gieben Expires September 2, 2005 [Page 19]
Internet-Draft DNSSEC Operational Practices March 2005
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.
Kolkman & Gieben Expires September 2, 2005 [Page 20]
Internet-Draft DNSSEC Operational Practices March 2005
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
Kolkman & Gieben Expires September 2, 2005 [Page 21]
Internet-Draft DNSSEC Operational Practices March 2005
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 proposed new text ----
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
