Subject: draft-kolkman-dnssec-operational-practices-00.txt

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 25 Aug 2003 09:26:47 +0200

Colleagues,

draft-kolkman-dnssec-operational-practices-00.txt is now in the I-D
repository.

To give you an idea about content the abstract and index are copied
below.

Does the working group want to accept this document as a working group
item?

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

Abstract

   This Internet-Draft is intended as a place holder for considerations
   and operational practices for DNSSEC key-management.  It is intended
   to be 'long-lived' and result in documentation of best(?) current
   practices.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1   Time definitions . . . . . . . . . . . . . . . . . . . . . .  3
   2.2   Time considerations  . . . . . . . . . . . . . . . . . . . .  4
   3.    Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1   Using Key-Signing and Zone-Signing Keys. . . . . . . . . . .  6
   3.1.1 Motivations for the KSK and ZSK functions  . . . . . . . . .  6
   3.2   Key security considerations  . . . . . . . . . . . . . . . .  6
   3.3   Key rollovers  . . . . . . . . . . . . . . . . . . . . . . .  7
   3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . .  7
   3.3.2 Key-signing key rollovers  . . . . . . . . . . . . . . . . . 10
   4.    Planning for emergency key rollover. . . . . . . . . . . . . 11
   4.1   KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 12
   4.2   ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 12
   4.3   Compromises of keys configured at the resolver level . . . . 12
   5.    Parental policies. . . . . . . . . . . . . . . . . . . . . . 13
   6.    Initial key exchanges and parental policies
         considerations.  . . . . . . . . . . . . . . . . . . . . . . 13
   6.1   Storing keys so hashes can be regenerated  . . . . . . . . . 13
   6.2   Self signed keys during upload or not? . . . . . . . . . . . 13
   6.3   Security lameness checks.  . . . . . . . . . . . . . . . . . 13
   6.4   SIG DS validity period.  . . . . . . . . . . . . . . . . . . 13
   7.    Resolver key configuration.  . . . . . . . . . . . . . . . . 13
   8.    Security considerations  . . . . . . . . . . . . . . . . . . 13
   9.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 13
         Normative References . . . . . . . . . . . . . . . . . . . . 14
         Informative References . . . . . . . . . . . . . . . . . . . 14
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
   A.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . . 15
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 25 Aug 2003 13:31:48 -0400

An opinion on section 3.2 (Security Key Considerations):  It is the wrong
place for a discourse on key strengh, but a reference would be good for
further info for someone interested.  Otherwise, it might be good to give
some rough rules to follow such as "the larger the zone, the larger the key"
and "larger the zone, zone key rollovers should be more frequent".

I think this may help neophyte admins get a basic understanding.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Aug 2003 17:51:16 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:
    Olaf> draft-kolkman-dnssec-operational-practices-00.txt is now in the I-D
    Olaf> repository.

    Olaf> Does the working group want to accept this document as a working
    Olaf> group item?

  Yes, I think it should.

  I still would like to introduce some kind of term, like "dieletric constant
of DNSSEC" or some such to explain "propogation" of SIGs through caches :-)

  Some initial comments/thoughts:

>   o  "Key publication period"
>
>         The period for which the public part of the key is published in
>         the DNS.  The public part of the key can be published in the
>         DNS while it has not yet been used to sign data As soon as a
>         public key is published a brute force attack can be attempted
>         to recover the private key.  Publishing the public key in
>         advance (and not signing any data with it) does not guard
>         against this attack.

  One interesting "defense" against this would be to publish multiple
keys. Some of them could be total garbage. Since there is no signed data,
you'd have to brute force all them to figure out which one signed the data.

  But, in any case, if you believe that the key can be brute forced during
any low multiple of the "key publication period", then the period is probably
too short, or the keys too small.

re: 3.3.1.1 A double signature zone-signing key rollover

I don't think that at SOA#1, you have to resign with key 10. Maybe you
  have to sign the DNSKEY11, but that's it.
Also, I think that when you remove KEY10, that you wind up at SOA#2 as well.

>   Note that in this example we assumed that the zone did not get
>   modified during the rollover.  New data can be introduced in the zone
>   as long as it is signed with both keys.

  Is it strictly necessary to sign with a new key?

  At SOA#1, the trusted path is via KEY11. Since the new record, and
the DNSSIG record on the new data can't have been cached yet (since they
don't exist yet!), so signing with the old key is kind of irrelevant, I
think.

>3.3.1.2 Pre-publish keyset rollover
>
>   This section shows how to perform a ZSK key without the need to sign
>   all the data in ones zone twice.  We recommend this method because it
>   has certain advantages in the case of key compromises.  A small
>   "HOWTO" for this kind of rollover can be found in Appendix B.

  It would be good to explain this.
  The major advantage is that it costs only 1 DNSKEY record, vs
O(size-of-zone) DNSSIG records.

>4.1 KSK compromise
>
>   When the KSK has been compromised the parent must be notified as soon
>   as possible and in a secure means.  The keyset of the zone SHOULD

  I believe that we should have a BCP for this part.
  What does it mean to securely notify the parent -- this is a human
protocol, not necessarily just a network one.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Miek Gieben <[email-masked]>
Date: Thu, 28 Aug 2003 12:02:55 +0200

[On 25 Aug, @19:31, Scott wrote in "Re: draft-kolkman-dnssec-opera ..."]
> and "larger the zone, zone key rollovers should be more frequent".

thanks, I've added this. I think it is good to make such a non technical
statement about key sizes.

References to documents regarding key sizes is still a good idea, but I don't
want to specify exact sizes in this draft. 

I do however have a document at home which has a table: year <-> key length. You
can just look up the year and then find a key length. This runs up until the
year 2025 (or something). Maybe that should be added as an reference...

grtz Miek

---

From: Miek Gieben <[email-masked]>
Date: Thu, 28 Aug 2003 12:37:44 +0200

[On 25 Aug, @23:51, Michael wrote in "Re: draft-kolkman-dnssec-opera ..."]
> of DNSSEC" or some such to explain "propogation" of SIGs through caches :-)

Well, we already have the "singing zone rollover" :-)

> too short, or the keys too small.

yes, but I'm not sure is something of this wording should be put in, although I
like the idea of "garbage keys".

>   have to sign the DNSKEY11, but that's it.

the idea is to go from key10 to key11, both ZSKs. The thing is that caches
which do have key 10 but not any data can stil get data from the zone which
is signed with key 10.

after key 10 is timed out, the cache will pick up the keyset with keys
10 and 11. So now key 11 is in play. 

> Also, I think that when you remove KEY10, that you wind up at SOA#2 as well.

When this has happened key 10 can be discarded from the zonefile. So this
is what actually happens. Or are you saying, to go from SOA#0 to SOA#2 simple
discard key 10? But as I tried to explain above will not work. 

> don't exist yet!), so signing with the old key is kind of irrelevant, I

it's all about old data which is signed with the old key. We wanted to 
specify some sort of transition from key 10 to key 11.

>   It would be good to explain this.

Maybe adding something like this would help?:

If the old key gets compromised the new key is already distributed in the DNS. A
zone administrator is than able to quickly switch to the new key and remove the
compromised key from the zone.

> O(size-of-zone) DNSSIG records.

yes, true, took me a moment to parse this, but you mean that you don't need
to have a double signed zone (which could be really big). 

>   I believe that we should have a BCP for this part.

a seperate one? Or be just more verbose in this one?

> protocol, not necessarily just a network one.

I have no idea what is means, it probably means don't use the DNS.... :)

thanks for your comments,

grtz Miek

---

From: David Meyer <[email-masked]>
Date: Thu, 28 Aug 2003 16:17:35 -0700

>> Sure sounds to me like something this WG ought to be doing.

Agree, and thanks for speaking up Rob (hat on or off).

Dave

[in the immortal works John Aaron, "try SCE to AUX"]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Thu, 28 Aug 2003 19:12:50 -0400

<hat wg-co-chair=on>

  Any objections?

</hat>

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 29 Aug 2003 07:29:10 -0400

None from me.  I would like to see this a WG document.

Scott

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 29 Aug 2003 08:43:36 -0400

The key length <-> year sounds like a good reference doc.  I'm sure the hard
core security folk will want to consider other factors too (size of
plaintext, etc.) but admins that do not have the time to study up on
cryptography will want a handy guide.  That and the other rules I talked
about should give admins new to DNSSEC a place to start.

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Aug 2003 11:50:02 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Miek" == Miek Gieben <[email-masked]> writes:
    >> But, in any case, if you believe that the key can be brute forced
    >> during any low multiple of the "key publication period", then the
    >> period is probably too short, or the keys too small.
                              ^long

  Sorry.

    Miek> yes, but I'm not sure is something of this wording should be put
    Miek> in, although I like the idea of "garbage keys".

  If you are very paranoid.

    >> It would be good to explain this.

    Miek> Maybe adding something like this would help?:

    Miek> If the old key gets compromised the new key is already distributed
    Miek> in the DNS. A zone administrator is than able to quickly switch to
    Miek> the new key and remove the compromised key from the zone.

  Yes.

    >> O(size-of-zone) DNSSIG records.

    Miek> yes, true, took me a moment to parse this, but you mean that you
    Miek> don't need to have a double signed zone (which could be really
    Miek> big).

  Yes, that's the point.
  It means that nearly all large zones would want to pre-publish the next
key.

    >> I believe that we should have a BCP for this part.

    Miek> a seperate one? Or be just more verbose in this one?

    >> protocol, not necessarily just a network one.

    Miek> I have no idea what is means, it probably means don't use the
    Miek> DNS.... :)

  A seperate BCP on the human protocol for indicating a compromise of a key
via out-of-band protocol.