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

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Jun 2010 17:15:39 -0400

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Jun 2010 14:34:47 -0700

On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson <[email-masked]> wrote:
> 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.

I know I'm repeating myself, but this is simply not correct for any plausible
lifetimes or key sizes I've provided my analysis several times:

http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html

If you have some analysis that supports this argument please post it.

-Ekr

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Jun 2010 18:30:26 -0400

On 17/06/2010 5:34 PM, Eric Rescorla wrote:
> On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson<[email-masked]>  wrote:

Ekr,

I agree with you but there are still people out there that believe
that key size is a tradoff in time.
Remember I'm arguing against the KSK+ZSK split in most cases, a 
different thread will be started on key size recommendation.

This should be another recommendation for changes in rfc4641-bis

	Olafur

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 18 Jun 2010 10:43:35 -0400

> selection of single vs Role based keys:
Algorithm and key size used?  

Other potential parameters:
response size (i.e. average response size from zone)
update/zone change policy and frequency (considering roles below)
negative response method (again, considering roles)

> States: Inactive, Active, Revoked

Why not use the same terms from draft-morris-dnsop-dnssec-key-timing-02?  

Otherwise, I think the proposals are sound.

Scott

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
===================================

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jun 2010 12:35:31 -0400

>that key size is a tradoff in time.

"Belief" - engineering shouldn't be about beliefs.

I think the hard part for many of us to grasp is that for many years 
the conventional wisdom of the DNSSEC practitioners was that "size 
mattered" and now we are hearing differently.  It might be good to 
have a document that refutes the notion that size matters in a way 
that is convincing to DNS'ers (as Olafur alludes to).

(My operational insistence on regularly changing the keys is no 
longer based on the "size matters" argument.  There are other 
operational considerations and the lack of a revocation mechanism for 
DNSSEC key material.)

>Remember I'm arguing against the KSK+ZSK split in most cases, a different
>thread will be started on key size recommendation.

I don't think KSK+ZSK is a dead or outmoded idea.  One thing Olafur 
didn't mention was the presence of EPP which wasn't foreseen when the 
KSK+ZSK concept was conceived.  EPP is one more advance that makes 
single key systems attractive, but EPP isn't everywhere and not all 
registries have quick response as a goal.  (By that I mean the root 
zone prioritizes checking each change over getting it done in an 
hour.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

The World Cup would be more fun if they didn't interrupt it with soccer games.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Jun 2010 13:29:13 -0400

On Fri, Jun 18, 2010 at 12:35:31PM -0400, Edward Lewis wrote:
> I don't think KSK+ZSK is a dead or outmoded idea.  

If I understand Olafur correctly, he doesn't either.  He just thinks
that in a large number of cases, it's not the right approach to
achieve the goal of reliable operation (including the reliable
availability of data for validation).

I agree with him, and tried to make this point in Anaheim.  The
arguments for KSK/ZSK splits are at best appropriate for certain
classes of operation, and I don't think we should publish a document
that says that such a split is generally speaking a best practice.  I
think the arguments for that claim are weak, because there is
countervailing evidence to the effect that a single key in the right
circumstances will be more reliable and less likely to be messed up by
operator error.  That is especially true for smaller zones without
professional administrators.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 19 Jun 2010 12:01:36 -0400

On 18/06/2010 12:35 PM, Edward Lewis wrote:
> I think the hard part for many of us to grasp is that for many years the
> conventional wisdom of the DNSSEC practitioners was that "size mattered"
> and now we are hearing differently. It might be good to have a document
> that refutes the notion that size matters in a way that is convincing to
> DNS'ers (as Olafur alludes to).
>

The topic that EKR is aginst the practice of frequently rolling
a weak RSA1024 bit. He is recommending that people use a strong
key in the first place.

> (My operational insistence on regularly changing the keys is no longer
> based on the "size matters" argument. There are other operational
> considerations and the lack of a revocation mechanism for DNSSEC key
> material.)

Different domains are going to have different "rollover requirements"
irrespective of how many keys are used.
Please stay on topic:
Should the WG document recommend/bless single key usage in
some/many cases.

> KSK+ZSK concept was conceived. EPP is one more advance that makes single
> key systems attractive, but EPP isn't everywhere and not all registries
> have quick response as a goal. (By that I mean the root zone prioritizes
> checking each change over getting it done in an hour.)

Thank you Ed for bringing up a good point that I missed.
When EPP is used and the intermediary supports passing DS records
the child can update its DS set as easily as most people maintain their
NS records.

	Olafur

---

From: Edward Lewis <[email-masked]>
Date: Tue, 22 Jun 2010 09:43:34 -0400

At 12:01 -0400 6/19/10, Olafur Gudmundsson wrote:

>Should the WG document recommend/bless single key usage in some/many cases?

No.

The tradeoffs should be documented, sure.  Alternatives discussed, 
sure.  But I find recommendation documents fall out of fashion very 
quickly.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "George Barwood" <[email-masked]>
Date: Thu, 24 Jun 2010 10:59:19 +0100

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, June 19, 2010 5:01 PM
Subject: Re: [DNSOP] That key size argument...was Re: The case for single active key

> Should the WG document recommend/bless single key usage in

Not sure about recommending, but "bless", yes.

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

There is no need for the DNSKEY RRset to be signed in this case, although of course
for compatibility it is necessary - but maybe one day in the very far future the SHOULD
above can become a MUST, and the requirement to provide an RRSIG can even later be relaxed.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 24 Jun 2010 12:38:38 +0200

Hi George,

> where all the keys are validated by DS records.

This is not possible, and Casey thought similarly, so here is text:  The
RRSIG from a DNSKEY identified by a DS record must validate.  You must
do this to ensure that you have obtained all DNSKEY RRs.  And thus know
all of the algorithms in use.  And thus know which algorithms MUST have
signatures over the zone content.  This is from RFC4035.

> above can become a MUST, and the requirement to provide an RRSIG can even later be relaxed.

No.  Algorithm rollover is very important, as one day cryptography
advances may impose new algorithm constraints.

Best regards,
   Wouter

---

From: "George Barwood" <[email-masked]>
Date: Thu, 24 Jun 2010 13:56:29 +0100

----- Original Message ----- 
From: "W.C.A. Wijngaards" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, June 24, 2010 11:38 AM
Subject: Re: [DNSOP] That key size argument...was Re: The case for single active key

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi George,
> 

Ok, I see your point. 

However counter-examples seem to depend on having multiple keys for the same algorithm, e.g.

Zone signing is with 1024-bit RSA and GOST.
There are DS records for the 2048-bit RSA and 1024-bit RSA, but no DS for GOST.

Here there is a down-grade attack where the attacker chops the GOST key.

So maybe the optimisation can still be done under the additional condition that there is only 1 key for each algorithm. Can you see a problem with that?

George

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Jun 2010 08:42:55 +1000

> signatures over the zone content.  This is from RFC4035.

RFC 4035 is overly prescriptive.  The MUST applies for algorithms
publish in DS's or trust anchors.  It was put there to prevent you
thinking a zone should be treated as secure and then not finding
signatures that you could use.  If the algorithm is not listed in
DS records and is not listed in published trust anchors then it
does not matter whether all records are signed by the algorithm.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkwjNa4ACgkQkDLqNwOhpPgi0ACgjxFbRXFHPhoG0C/olJt7QdDf
> dRAAoKjSPZK+RVlSMjyLbEgMDn3fBV/F
> =UkYT
> -----END PGP SIGNATURE-----
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]