Subject: [dnsop] Comments on key rollover req. draft

From: Samuel Weiler <[email-masked]>
Date: Tue, 9 Nov 2004 15:51:38 -0500 (EST)

This document has a number of unjustified and mutually exclusive
requirements.  To wit:

   From Section 2: "... the child zone must contact its parent zone
   and must notify it about the KSK change(s)."  Some proposed schemes
   involve the parent polling the child.  Those schemes may be
   unwise, but "must" seems overbroad and certainly unjustified by
   the text in this document.

   Later in section 2: "the security of these communications [in
   manual rollovers] is out of scope of DNSSEC."  Not necessarily.  A
   child might manually add new keys, intending that they be
   authenticated in-band, then contact the parent out-of-band to
   trigger the update (a process that may not need to be secured),
   then the parent fetches the key keys in-band.

   In section 3, I'm not sure what is meant by "Every RR MUST be
   verifiable at any time..."  In any case, I hope "every RR" does not
   include "every RRSIG" -- I'd like to allow publication of RRSIGs
   even when the DNSKEYs that created them aren't available.

   Section 4 has an unjustified requirement for in-band
   authentication: "Every exchanged message MUST be authenticated and
   the authentication tool MUST be a DNSSEC tool..."  Unless we're
   limiting this document's scope to in-band rollover, this is grossly
   inappropriate.

   The next paragraph of section 4 has another unjustified
   requirement: "... a child zone,... MUST notify its parent
   zone...".  Why is this document trying to disallow parent polling?

   The next paragraph of section 4 is similarly flawed.  It requires
   transmission of keys, apparently prohibiting transfer of DS
   records or key hashes, as suggested in Scott Hollenbeck's EPP
   draft.  Where's the justification?

   Section 5 adds a requirement ("[a compromised] key MUST be changed
   as soon as possible") that is perhaps unnecessary.  The section
   admits that this may cause validation failures, in direct conflict
   with requirements in section 4 ("...at any time ... all RRs MUST be
   verifiable, even if an error occurs") and section 3 ("Every RR MUST
   be verifiable at any time...").

   Section 6 requires the parent NS set to change whenever the child
   NS set changes.  No matter the preferences of the protocol purists,
   this is not how the real world works.

I think the requirements I've picked apart above comprise such a large
portion of this document that the WG would be better off starting from
scratch than trying to fix the current document.  Therefore, I suggest
that DNSOP abandon this draft.

-- Sam
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 10 Nov 2004 10:13:56 -0500

As mentioned in the WG meeting:  Looking back on the RFC2541 draft, it
mostly deals with key generation and lifetime requirements.
draft-ietf-dnsop-dnssec-operational-practices-02 covers much more ground
with operation procedures for key rollovers.

RFC 2541 also gives hard numbers for key length minimums and lifetimes,
which may not always hold in different deployments.  For example:
Transaction security keys have a suggesed max lifetime of 36 days.  It also
only addresses RSA/MD5 which is now not recommeded for DNSSEC.  So while a
initial document for DNSSEC deployment, it does not address several key
items in maintaining a secure tree.

I would therefore like to see the new draft obsolete RFC2541 and progress as
an informational RFC.

Scott

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 10 Nov 2004 10:57:15 -0500

>I would therefore like to see the new draft obsolete RFC2541 and progress as
Where 'the new draft' refers to dnssec-operational-practices.

Miek, Rip and myself are looking at how we can merge the relevant parts. 
If the WG thinks this is a good idea we'll proceed.  (That is, please 
shout "STOP" asap if you do not want us to put it in operational 
practices. :-) )

--Olaf
.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 10 Nov 2004 11:06:05 -0500

> -----Original Message-----
> From: Olaf M. Kolkman [mailto:[email-masked]]
>

I am not yelling stop yet.  I would suggest dropping all language regarding
specific key lengths and lifetimes.  Or at least make it clear they are
recommend values and can be superceeded by local policy.  It would also be
nice to find a good reference to back up any recommended values - especially
when it comes to key length.  Some people take that serious for some strange
reason ;-)

Scott

.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 11 Nov 2004 15:06:12 +0100

[On 09 Nov, @ 21:51, Samuel wrote in "[dnsop] Comments on key rollov ..."]
> This document has a number of unjustified and mutually exclusive

in the dnssec-operational draft, we have the following:

3.3.4  Automated Key Rollovers

   As keys must be renewed periodically, there are some motivation to
   automate the rollover process (also see [12])

   o  ZSK rollovers are easy to automate as only the local zone is
      involved.
   o  A KSK rollover needs interaction between the parent and child.
      Data exchange is needed to provide the new keys to the parent,
      consequently, this data must be authenticated and integrity must
      be guaranteed in order to avoid attacks on the rollover.
   o  All time and TTL considerations presented in Section 3.3 apply to
      an automated rollover.

which in my mind sums it all up, so I would favor dropping the key req.
draft,

grtz Miek
.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 16:14:56 +0000

> which in my mind sums it all up, so I would favor dropping the key req.

This doesn't say anything about SEP keys, though.

Cheers,

Ben.
.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 11 Nov 2004 17:24:37 +0100

[On 11 Nov, @ 17:14, Ben wrote in "Re: [dnsop] Comments on key ro ..."]
> This doesn't say anything about SEP keys, though.

it talks about ksk keys, which are implied to be sep keys (that is
defined somewhere else in the doc)

grtz Miek
.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 16:44:44 +0000

> defined somewhere else in the doc)

SEP keys do not have a parent!
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 11 Nov 2004 14:12:38 -0500

> SEP keys do not have a parent!

Sep keys are the secure entry points into a _zone_. Not the secure entry 
points into the DNS (although sometimes a
secure entry point into a zone is also a secure entry point into the 
DNS, that is when a SEP key is configured as trust anchor.)

The definition is subtle, see RFC3757.

--Olaf
.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 11 Nov 2004 21:57:07 +0000

> The definition is subtle, see RFC3757.

Sorry, then I used the wrong term (seems to me that SEP vs KSK wasn't a 
step forward, but whatever). My objection should have been:

This doesn't say anything about trust anchors, though. .

Cheers,

Ben.
.

---

From: David Blacka <[email-masked]>
Date: Thu, 11 Nov 2004 22:22:33 -0500

On Nov 11, 2004, at 4:57 PM, Ben Laurie wrote:

>> Sep keys are the secure entry points into a _zone_. Not the secure 
>> entry points into the DNS (although sometimes a
> Sorry, then I used the wrong term (seems to me that SEP vs KSK wasn't 
> a step forward, but whatever). My objection should have been:

The reason why SEP is used for the name of the flag (and thus DNSKEYs 
with that flag set) instead of KSK is because KSK implies an 
operational model that may or may not be in use.

Secure Entry Point is what the key *is*, Key Signing Key is what the 
key *does*.

--
David

.

---

From: Johan Ihrén <[email-masked]>
Date: Sat, 13 Nov 2004 09:53:52 +0100

> Secure Entry Point is what the key *is*, Key Signing Key is what the 

That's very good distinction that clearly explains the name.

Johan

.

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 15 Nov 2004 09:35:36 -0500 (EST)

> [Allowing the child to send both DS and DNSKEY] adds some
> complexity.  Is the benefit worth it or not?

Yes.

The hash function (digest) field in the DS record can be used for
signaling, so the child should have some way of specifying the DS hash
algorithm.  Allowing the child to specify the entire DS record seems
more sensible than adding a digest data element to the EPP key spec.

An example: draft-ietf-dnsext-dnssec-trans-01.txt talks about using
algorithm numbers for signaling a protocol change in the child zone.
DS hash algorithm numbers could be used in the same way.  This is
perhaps not very wise, but it may well work.

-- Sam
.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Nov 2004 10:22:11 -0500

>>  complexity.  Is the benefit worth it or not?

Why?  (The rest is just commentary on the DS option...)

>more sensible than adding a digest data element to the EPP key spec.

What part of a DS RR's rdata is not in a secDNS:dsData element?

>perhaps not very wise, but it may well work.

Let's burn that bridge when we come to it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar

I would have been at the meeting, but I was busy raking the leaves from
the (now) empty non-terminals in my yard.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 15 Nov 2004 10:25:39 -0500 (EST)

> Why?  (The rest is just commentary on the DS option...)

Because it may be useful for the child to select the DS digest
algorithm, the DNSKEY option (in this draft) has no way to specify
the digest, and allowing the child to send DS (by keeping the
dsData element) seems simpler than adding a new element to the key
spec.

> What part of a DS RR's rdata is not in a secDNS:dsData element?

None.  I'm arguing that we should keep the dsData element as an
option.

-- Sam
.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Nov 2004 10:38:42 -0500

>None.  I'm arguing that we should keep the dsData element as an

Why keep the DNSKEY option?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-571-434-5468
NeuStar