Subject: [DNSOP] KSK rollover

From: "George Barwood" <[email-masked]>
Date: Thu, 13 May 2010 08:56:03 +0100

I have been thinking about KSK rollover in my DNSSEC implementation, and it seems
that there is currently no  specification for KSK rollover within the DNSSEC protocol.

There is this expired requirements draft

http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-key-rollover-requirements/

but that's all I found.

Have I missed something? It seems to me that this is a rather vital component if
DNSSEC is to be widely deployed.

Are there any plans to revive and/or implement these requirements?

George Barwood

---

From: Patrik Wallstrom <[email-masked]>
Date: Thu, 13 May 2010 10:06:46 +0200

> Are there any plans to revive and/or implement these requirements?

You probably want to read the Key Timing Considerations draft:
http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02

---

From: "George Barwood" <[email-masked]>
Date: Thu, 13 May 2010 17:37:42 +0100

----- Original Message ----- 
From: "Patrik Wallstrom" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 13, 2010 9:06 AM
Subject: Re: [DNSOP] KSK rollover

> http://tools.ietf.org/html/draft-morris-dnsop-dnssec-key-timing-02

That is certainly relevant to rollover, but it doesn't specify any means by which
the new DS records can be placed in the parent zone.

http://tools.ietf.org/html/rfc5011 "Automated Updates of DNS Security (DNSSEC) Trust Anchors"

has some relevance, but doesn't provide for parent notification, or for publishing
a DS record *before* the key is published in the zone, which is I think desirable.

The mechanism that occurs to me is to have a new RRtype, say "CDS", with identical
format to the DS record, but placed in the child zone ( and signed by the child zone).
The parent, at regular intervals, or on receiving a notification from the child, would
retrieve the contents of the CDS RRset, and use it as the new DS RRset ( of course
after validating it using the old DS RRset ).

There probably needs to be consideration of how the system can recover after
a KSK is compromised, maybe there should be some minimum time interval
before a new DS record is fully trusted. I have not thought that through.

Well, that's just my immediate thoughts, there may be a better way.

I'm somewhat puzzled that thre is no specification, and apparently no activity on this.

KSK rollover is probably a fairly rare event (maybe once every few years), so possibly
the feeling is that manual procedures will be sufficient. I think a standardized, automated
in-protocol mechanism would be advisable though. Maybe I'm wrong.

Best regards,
George

---

From: Evan Hunt <[email-masked]>
Date: Thu, 13 May 2010 17:25:54 +0000

> That is certainly relevant to rollover, but it doesn't specify any means
> by which the new DS records can be placed in the parent zone.

You're correct, there's no mechanism for doing this within the DNS.  You
need to update DS records through your registrar just as you do with NS
records and glue.

I hear there's an effort under way to develop an in-protocol mechanism
for DS tracking, but I don't know how far along it is.

> The mechanism that occurs to me is to have a new RRtype, say "CDS", with
> identical format to the DS record, but placed in the child zone ( and
> signed by the child zone).

You've got a chicken-egg problem there: How does the parent know it
should trust the key that signed the CDS?

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 May 2010 13:38:41 -0400

>I'm somewhat puzzled that thre is no specification, and apparently no

http://www.ripe.net/ripe/meetings/ripe-59/presentations/lewis-dnssec.pdf

There's activity.  There's no standard underway because of the 
plethora of situations.  There are proposed solutions that extend 
DNS, some extend EPP, and sooner or later some will extend other 
provisioning protocols.

I doubt we will come to one standard practice.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 May 2010 09:33:24 +1000

In message <44C21CD9EE514B039EAFEAFA707A2DA1@local>, "George Barwood" writes:
> That is certainly relevant to rollover, but it doesn't specify any means by
> which the new DS records can be placed in the parent zone.
> 
> has some relevance, but doesn't provide for parent notification, or for
> publishing a DS record *before* the key is published in the zone, which
> is I think desirable.

	RFC5011 really isn't applicable to this case.
 
> signed by the child zone). The parent, at regular intervals, or on
> receiving a notification from the child, would retrieve the contents of
> the CDS RRset, and use it as the new DS RRset ( of course after validating
> it using the old DS RRset ).

	There are lots of way to do this.
	* Use UPDATE to update the delegation records in the parent.
	  This would work today it only requires a willingness to do so.
	  This can be done securely (TSIG) and will scale.
	  UPDATE was designed to support this.
	* Try to guess which keys should have DS's based on SEP bits.
	* Use a different RR type (DLV does this).  poll/notify to
	  incorporate.  (Ed the daily delegation check could do this. :-))
	* Use some epp extension.
	* Use a modified UPDATE which accepts and forwards to the
	  registrar for inclusion in the zone rather than immediately
	  updates the zone.  When a registrar is not involved it is
	  handled as a plain UPDATE.
	* ....

> I'm somewhat puzzled that thre is no specification, and apparently no

	There is plenty of activity.  Most of it has been people
	looking at how to fit this into the registry/registrar model
	and worries about patent infringement that are claimed to
	have been filed for some of the above.  I doubt that any
	thing we do in this area is truly novel but the USPO grants
	patents on such trivial things that its become a issue.

	Mark

> KSK rollover is probably a fairly rare event (maybe once every few years), so
> possibly the feeling is that manual procedures will be sufficient. I think a
> standardized, automated in-protocol mechanism would be advisable though.
> Maybe I'm wrong.
> 
> Best regards,
> George
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 May 2010 22:13:43 -0400

> 	  handled as a plain UPDATE.

... and there's also the approach that is actually being implemented, which is described in RFC 4310.

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 13 May 2010 22:17:08 -0400

> ... and there's also the approach that is actually being implemented, which is described in RFC 4310.

Or 5910, since that seems to exist now. :-)

Internet Engineering Task Force (IETF)                          J. Gould
Request for Comments: 5910                                 S. Hollenbeck
Obsoletes: 4310                                           VeriSign, Inc.
Category: Standards Track                                       May 2010
ISSN: 2070-1721

          Domain Name System (DNS) Security Extensions Mapping
             for the Extensible Provisioning Protocol (EPP)

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 May 2010 12:32:54 +1000

In message <[email-masked]>, Joe Abley writes
> which is described in RFC 4310.

Which is essentially registrar to registry.  It really does not
make for a general solution to the problem unless every operator
of every zone that delegates any zone runs epp in addition to running
a DNS server.

Mark

---

From: Joe Abley <[email-masked]>
Date: Fri, 14 May 2010 00:16:06 -0400

> of every zone that delegates any zone runs epp in addition to running

Sure, but be aware that you're conflating several of

 - delegated zone editor
 - delegated zone publisher
 - authoritative nameserver operator for delegated zone
 - registrant
 - registrar
 - registry
 - parent zone editor
 - parent zone publisher
 - authoritative nameserver operator for the parent zone

in your general solution, which makes it no more general, really. Granted there are probably not often nine different entities carrying out those functions, but increasingly there are more than two.

The EPP answer at least has some basis in current reality.

I suspect there is no general solution.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 14 May 2010 16:06:01 +1000

In message <[email-masked]>, Joe Abley writes
:
> in your general solution, which makes it no more general, really. =
> Granted there are probably not often nine different entities carrying =
> out those functions, but increasingly there are more than two.
> 

On the other hand I'm sure that there is a general solution.
We need to define how the child talks to the parent so that
the parent can be sure that it is the child making the request.

The rest depends on the business models the parent and child are
using.

child component with authority to update ->
	PROTOCOL ->
		 parent component the authority to accept update from child ->
			parent processes ->
				 published zone.

parent processes could be:
	forward to registrar
	registrar authenticates send back ack/nak via parent component
	convert to epp and update registry
	registry publishes.

or they could just be:
	authenticate
	update parent zone
	send back ack/nak

Mark

---

From: "George Barwood" <[email-masked]>
Date: Sat, 22 May 2010 09:50:46 +0100

Well, I have uploaded a draft :

http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt

Comments and/or indications of support are of course welome, on or off list.

George

----- Original Message ----- 
From: "George Barwood" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, May 13, 2010 8:56 AM
Subject: [DNSOP] KSK rollover

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

---

From: Chris Thompson <[email-masked]>
Date: 22 May 2010 20:07:54 +0100

>Comments and/or indications of support are of course welome, on or off list.

Section 3:

| The CDS record MUST be signed with a Key Signing Key, that is a key
| for which there is a DS record.

(a) That's a new definition of "key signing key", I think. RFC3757 comes
    closest with KSK = key with SEP bit = "which DNSKEYs are to be sent
    for *generating* DS RRs" (my emphasis), but I take it you mean a key
    for which a DS record *already* exists.

(b) Why? Why shouldn't a chain of trust through (say) a KSK and a ZSK 
    be enough? Insisting on a one-step chain seems contrary to the
    spirit, at least, of RFC 4034 section 2.1.1.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: "George Barwood" <[email-masked]>
Date: Sat, 22 May 2010 21:15:59 +0100

Chris,

Thanks for your comments.

----- Original Message ----- 
From: "Chris Thompson" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, May 22, 2010 8:07 PM
Subject: Re: [DNSOP] KSK rollover

>    for which a DS record *already* exists.

Ok - so I guess I should just possibly say simply:

"The CDS record MUST be signed with a key for which there is a DS record."
 
>    spirit, at least, of RFC 4034 section 2.1.1.

My reasoning is that

(i) Zone signing keys are used more frequently than a KSK, since they are needed whenever the
zone content changes ( in particular if dynamic update is supported, the ZSK must be kept online ).
Therefore Zone signing keys are more exposed to compromise. They also tend to be shorter, and
are therefore possibly easier to crack.

(ii) The CDS record is not verified during normal operation, so any cost associated with
the longer signature does not matter.

(iii) My intuition suggests that access to a Zone signing key should not give permission 
to update the CDS RRset.

This reasoning may not hold up under closer scrutiny, it's just my take on it ( and as the acknowledgments
mention, I received a hint on this from Olafur Gudmundsson - maybe he has better insight into this )).

Re RFC 4034, section 2.1.1 : isn't that simply saying that "all" keys have Bit 7 set in the flags field?
Both Zone Signing Keys and Key Signing Keys are "Zone keys", inasmuch as they are used to 
verify RRSIGs.

[ By "all" I mean all DNSSEC keys that we use today ]

Regards,
George