Subject: Re: [DNSOP] RFC4641-bis: The case for single active key

From: Olaf Kolkman <[email-masked]>
Date: Wed, 7 Jul 2010 15:35:18 +0200

On Jun 17, 2010, at 11:15 PM, Olafur Gudmundsson wrote:

> 
> Currently section 3 of the document "mandates" that all zones be signed using the KSK+ZSK model, I content this is outdated advice.

Version 02 of the draft offers the choice. And in fact it starts of by saying (in 3.1 second paragraph) that if you do not split KSK and ZSK functionality you should set the SEP flag on all keys in your keyset, thereby making the choice rather explicit up front.

I agree the document tends to give more arguments for than against a splitting KSK and ZSK functionality and that the final sentence of 3.1.1 is rather explicit in its advice. But mandate? 

Anyhow... some comments below...

> 
> Background #1: Why bring this up now
> While reviewing draft-ietf-dnsop-dnssec-dps-framework I found myself loving certain sections of the document and hating other sections.
> Before sending out a nasty review, I read the document over again and realized that the sections I hated were all derived from the recommendations in RFC4641, thus I'm starting few threads to talk about
> the major issues I have with this document.
> 
> Background #2: History of KSK+ZSK split
> I have been working on DNSSEC for a long time and during that time I have changed my mind on what is "good" a few times. The split key KSK+ZSK idea is good in certain environments but not in all.
> The original DNSSEC specifications did not have this split.
> The split was introduced after people realized that there might be breaks in the trust chain, or parents might be hard to update.
> The split is introduced by the DS draft (May 2001) and
> SEP flag draft (Sept 2002).
> The point of the SEP flag was to be able to pick out which DNSKEY(s) is supposed be configured as a DS in parent or a Trust Anchor.
> RFC5011 trust anchor maintainer should use the SEP flag while tracking
> changes.

I believe the SEP flag to be orthogonal to the choice of splitting the functionality. The SEP flag should be used to indicate that the key is intended as the "Secure Entry Point" into the zone. Section 3.1 of version 02 is rather explicit about this by saying that if you do not separate the functionality between KSK and ZSK you should always set the SEP flag.

Lets treat KSK and ZSK separation independent of the SEP flag.

Also, during editing I coiled the term "Common Signing Key" when the distinction between KSK and ZSK is not made.

> 
> Background #3: Key strengths and life time
> RSA and DSA algorithms have the interesting property that the number of bits in the key can be selected, by adding bits to the key the key gets stronger. Stronger keys can be used longer. The idea for KSK's was that the KSK would sign the DNSKEY rrset, be stronger than the ZSK and would live longer than the ZSK ===> reducing the load on parent in changing keys.
> But not all key algorithms have this variable key length property, for example ECC-GOST has fixed length, thus the stronger KSK argument does not apply.
> 

Agreed.

I modified the text in the document (see below) slightly to highlight that key-size differences are a weak argument for KSK-ZSK separation:

	Finally there is a risk of cryptanalysis of the key material.
	The cost of such analysis are correlated to the length of the
	key. However, cryptanalysis arguments provide no strong
	motivation for a KSK/ZSK split based on packet size
	considerations: If one differentiates between a KSK and a ZSK,
	requires that the resistance against crypto analysis is the
	same, and the amount of ZSKs rollovers during a KSK
	Effectivity (see <xref target="key_lifetime"/>) period is in
	the order 10s to 100s than the differences key sizes of the
	KSK and ZSK roughly are small enough not to significantly
	affect signing times or DNS packet length..

Not sure if this parses, feedback would be appreciated.

> Background #4: Difficulty in updating parents
> From a child zone perspective a parent can have one of the following behaviors:
> 	- unsigned
> 	- signed but refusing accepting DS[1]
> 	- signed but slower in updating than the child desires[2]
> 	- signed and easy to update.
> 
> [1] This can be either either parent policy or a deficiency by an
> intermediary such as the child's registrar.
> 
> [2] This can apply when update takes a while to show up in DNS
> or when the parent has LARGE TTL on the DS record thus it takes a long
> time for the old DS set to expire from caches.
> 
> In the first two cases having KSK+ZSK split may make sense.
> In the last case there is limited/no DNS operational need
> for split key operation.
> The third case is hopefully rare, and can be recommended out of existence.
> 

I think you are missing something here. A key may be configured as a trust-anchor. In which case a 3rd party interaction is needed. One that is even more difficult to control than the parental interaction. This is (IMHO) not academic: In enterprise environments it may be a requirement to have trust-anchor for ones own organization in order to not be dependent on external parties (at least to some extend).

Also, a rollover of a KSK will involve a state-change from a 3rd party; no matter how easy the update is. From a child perspective you have to wait for that state change to appear. The speed of signing and updating is not that relevant but predictability of the behavior is. I have a text proposal in the last paragraph of section 3.1.1 (see below)

> 
> Background #5: Signature size, signing time, DNSKEY set size.
> Strong KSK has larger signature and each signature takes longer to
> generate. But for small zone time difference is in the noise range and
> has to balanced against operational complexity.
> Having different keys in different roles makes the DNSKEY set larger.
> If a zone is small signing with 1536 bit RSA key vs 1024 makes
> practically no difference in either zone size or signing time,
> on modern hardware we are still talking about sub-second operation.

See #3

> 
> 
> Background #6: KSK can be protected better than ZSK as it is used less.
> But if the KSK and ZSK are stored together this is a bogus argument.
> 

In version 2 of the document that was already addressed by "While the arguments for differentiation... when the exposure to risk is low"

> 
> Background #7: Root/com will never be signed.
> During the early years of DNSSEC development and deployment there was
> uncertainty if the root zone would ever get signed. In this case there
> was seen need to have "stable" trust anchors for TLD's. Similar
> arguments were made that the com zone would never be signed.
> Well yesterday the root KSK was generated, com is planning to roll out
> DNSSEC early next year, the number of TLD's planning DNSSEC roll-out
> seems to be increasing.
> 
> For these reasons there is hope that we can migrate to a model were we
> assume that the upper parts of the DNS tree are signed. This
> reduces the need for "trust anchors of Islands of trust".

I am not sure if 'trust anchors of Islands of trust' have no operational needs. See my remark at #4. 

> The next pressure point will become the registrars.
> 
> Background #8: KISS
> It is much easier to explain to people how to do DNSSEC with a
> single key.
> When each key has a different role there is more of an opportunity for
> mistakes and confusion. We saw this recently with .arpa KSK signatures
> did not get updated, but signatures by ZKS were refreshed.
> 
> This goes to the core of the issue: If KSK is handled differently from
> the ZSK that increases possibility of mistakes/errors. Not all
> DNS operators are as sophisticated as Verisign (arpa DNS operator) who are not likely to repeat the mistake.

I feel a lot for this argument. I would like to make the choice for single type keys much more explicit while documenting all considerations and I hope that is achieved by the text below.

I will try to give some guidance on what pieces are irrelevant when the choice for a single type is made. In other words the text below is a current snapshot and subject to change over the next few days (and subject to working group consensus, off course)

(...)

Anyway... here is a strawman for section 3.1.1 that will probably end up in version 3 of the draft. (I hope to udate the draft before the deadline and I understand that this will all be subject to change based on WG consensus.)

Also see http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-dnsop-rfc4641bis-02.txt&url2=http://www.secret-wg.org/draft-ietf-dnsop-rfc4641bis.txt
for the diffs introduced by these edits.

and http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/KSK-ZSK-Split for a record of this 
issue.

---

3.1.1.  Motivations for the KSK and ZSK Separation

   Differentiating between the KSK and ZSK is mostly done for
   operational purposes.

   If the two functions are separated then, for almost any method of key
   management and zone signing, the KSK is used less frequently then the
   ZSK.  Once a key set is signed with the KSK, all the keys in the key
   set can be used as ZSKs.  If there has been an event that increases
   the risk that a ZSK is compromised it can be simply dropped from the
   key set.  The new key set is then re-signed with the KSK.

   Changing a key with secure entry point functionality (a SEP key) is
   relatively expensive as it involves interaction with 3rd parties:
   When a key is only pointed to by the parental DS one needs to

Kolkman & Gieben         Expires August 30, 2010                [Page 7]

Internet-Draft   DNSSEC Operational Practices, Version 2   February 2010

   complete the interaction with the parental registry and wait for the
   transaction to appear in the DNS.  In the case that a SEP key that is
   in use as a trust-anchor one has to wait until one has sufficient
   confidence that all trust anchors have been replaced.  In fact, it
   may be that one is not able to reach the complete user-base with
   information about the key rollover.

   There is also a risk that keys are compromised through theft or loss.
   For keys that are needed to sign dynamically updated records and are
   therefore installed on file-systems of nameservers that are connected
   to the network that risk is relatively high.  For keys that are
   stored on Hardware Signing Modules such risk is relatively low.  By
   separating the KSK and ZSK functionality these risks can be managed
   while making the tradeoff against the costs involved.  For example, a
   KSK can be stored off-line or with more limitation on access control
   than ZSKs which need to be readily available for operational purposes
   such as the addition or deletion of zone data.  More concretely a KSK
   stored on a smartcard, that is kept in a safe, combinded with a ZSK
   stored on a filesystem accessible by operators for daily routine may
   provide more operational flexibility and higher computational
   performance than a single key (with combined KSK and ZSK
   functionality) stored on an HSM.

   Finally there is a risk of cryptanalysis of the key material.  The
   cost of such analysis are correlated to the length of the key.
   However, cryptanalysis arguments provide no strong motivation for a
   KSK/ZSK split based on packet size considerations: If one
   differentiates between a KSK and a ZSK, requires that the resistance
   against crypto analysis is the same, and the amount of ZSKs rollovers
   during a KSK Effectivity (see Section 3.1.3) period is in the order
   10s to 100s than the differences key sizes of the KSK and ZSK roughly
   are small enough not to significantly affect signing times or DNS
   packet length..

   The arguments for differentiation between the ZSK and KSK are weakest
   when:

      the exposure to risk is low (e.g. when keys are stored on HSMs);

      if one can be certain that a key is not used as a trust-anchor;
      and

      the interaction -- in particular the appearance of a new DS record
      in the parent zone -- is predictable.

   If the above hold then the costs of the operational complexity of a
   KSK-ZSK split may outweigh the costs of operational flexibility and
   not separating zone and key signing functionality is then a

Kolkman & Gieben         Expires August 30, 2010                [Page 8]

Internet-Draft   DNSSEC Operational Practices, Version 2   February 2010

   reasonable option.  In other cases we advise that the separation
   between KSKs and ZSKs is made and that the SEP flag is exclusively
   set on KSKs.

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 8 Jul 2010 09:28:55 +0200

On Jun 24, 2010, at 11:59 AM, George Barwood wrote:

> It could also note that validators SHOULD NOT check the RRSIG for a DNSKEY RRset
> where all the keys are validated by DS records.

This document (4641-bis) is supposed to give operational guidance only. Implementation guidance for validators should (IMHO) go to another document.

--Olaf