Currently section 3 of the document "mandates" that all zones be signed
using the KSK+ZSK model, I content this is outdated advice.
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.
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.
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.
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.
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.
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".
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.
Proposal #1:
The document should describe both single key and split key operations
and provide real guidance as to when each model is appropriate.
Here is a draft of parameters that should be used to guide
selection of single vs Role based keys:
parent updatability
child zone importance
child zone size
Algorithm used
Proposal #2:
The document should describe the different roles keys can function in
and the states each key can be.
Roles: SEP, Zone signer, Update signer, Negative answer signer (RFC 4470)
States: Inactive, Active, Revoked
A key can be in one state but fill multiple roles.
An Example: dnssec-test.org is zone owned and operated by me, it is not
an important one.
Right now the parent zone (Org) does not accept DS updates (actually it
does via out of band mechanism)
My registrar may or may not accept DS records after ORG starts
accepting them in the near future.
In this situation the state of the parent+registrar should push me
towards two key operation.
The size and importance of the zone points towards single key
operation.
As my operation does not allow me to effectively store the key in the
KSK role differently from the ZKS.
==> dual key operation does not make sense.
==> Single offers operational and procedural advantages.
Thus I sign this zone with a single key.
The tools I use to sign the zone, by default scream at me for bad
operational model. When I filed a bug report the answer I got back was
"This operation is not in accordance with RFC4471"
When I commented that RFC4471 was not just the first attempt to
provide operational advice, the answer I got back was:
"You are an smart person and may do the right thing but we need to make
sure others follow best practices".
I agree with this statement and think this is a responsible position
by the vendor. For this reason I want this document to reflect
that in DNSSEC land multiple good practices exist and there is no
one-solution-fits-all
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
