Subject: [dnsop] on section 4.3 of dnssec-operational-practices

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 1 Jun 2005 16:34:57 +0200

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 6 Jun 2005 13:39:26 +0200

On Wed, 1 Jun 2005 16:34:57 +0200

> and fix the mistakes in the original text.

After my last message, Holger Zuleger, who is writing code based on
this draft asked me for clarification on what turned out to be a bug
in the text.

In section 4.2.1.1, the part about pre-roll. The part about "This
equates to two times the Maximum Zone TTL should be removed:

              force attacks on the public key.  The minimum duration
              of this pre-roll phase is the time it takes for the
              data to propagate to the authoritative servers plus
-             TTL value of the key set. This equates to two times the
-             Maximum Zone TTL.
+             TTL value of the key set. 

We plan to make this change in version 5.

Thanks Holger.

--Olaf
.