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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
