Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover

From: Chris Thompson <[email-masked]>
Date: 05 Jul 2011 20:48:08 +0100

On Jun 30 2011, Olafur Gudmundsson wrote:
[... snip ...]
>It would be nice, and make the system more robust. FWIW I think NS can 
>be automatically maintained after we have DNSSEC by having the parent 
>copy what the child publishes.

At first sight this looks as though it only involves the parent and
child, but there could be problems with automatically updating glue.
The authoritative value of "required glue" may come from a grandchild
zone which is not signed, even if the child is, and "sibling glue"
could similarly involve unsigned zones.

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

---

From: Chris Thompson <[email-masked]>
Date: 05 Jul 2011 21:09:20 +0100

On Jun 12 2011, George Barwood wrote:

>I have updated the draft
>
>http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-02.txt
>
>I have added an appendix with an exampler KSK rollover, and made
>various generally minor changes.
>
>IANA have now assigned type code 59 for the CDS RRtype.
>
>I'd like to request that the WG adopt this document.

While everyone else is discussing policy issues, can I raise a
technical one?

| The CDS record MUST be signed with a key that has the Secure Entry
| Point flag set.
[...]
| The parent zone SHOULD check that the signing key(s) have the Secure
| Entry Point flag set.

This is changed from the first draft, replacing "KSK" by "SEP flag".
but it still doesn't make sense to me. The draft doesn't seem to
contain any indication as to why this is desirable.

Not all signed zones have a key with the SEP flag set. I don't see why
they should be excluded from using this mechanism.

Obviously, the intent isn't that that the CDS *refer* to a key with the
SEP flag set, as this is unenforceable if the key hasn't even been
published yet (as suggested in section 1).

If the intent is to minimise the length of the chain of trust being
used, then "MUST be signed with a key for which the parent already
holds a DS record" would be the appropriate modification. But is
this really necessary?

---

From: "George Barwood" <[email-masked]>
Date: Tue, 5 Jul 2011 22:22:09 +0100

----- Original Message ----- 
From: "Chris Thompson" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 05, 2011 9:09 PM
Subject: Re: [DNSOP] CDS RRtype - automated KSK rollover

> holds a DS record" would be the appropriate modification. But is

The intent is to restrict the ability to update the parent DS to those who have
access to key signing keys. Thus where there is a split responsibility ( similar to
the root zone where IANA has the KSK private key, and Verisign has only the
ZSK private key ), only the senior party can update the parent DS.
The party that only holds the ZSK private key cannot update the parent and
take over the zone. 

George

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 05 Jul 2011 17:42:06 -0400

> could similarly involve unsigned zones.

Well is this any worse than what we have today with 
stale/unneeded/forged glue ?

It is not just grand child glue we need to worry about it is sibling 
glue and glue loops.

I do not know what is the right answer :-)

	Olafur

---

From: Chris Thompson <[email-masked]>
Date: 06 Jul 2011 17:25:28 +0100

On Jul 5 2011, George Barwood wrote:

>access to key signing keys. Thus where there is a split responsibility (similar
>to the root zone where IANA has the KSK private key, and Verisign has only the

OK - maybe I should have thought of that, but I think it does need to be made
clear in the draft.

But it remains the case that not all signed zones have this division of
responsibilities[*], or even have separate KSKs and ZSKs. Maybe this
ought to be a policy matter for each parent-child pair, rather than a
protocol MUST/SHOULD.

[*] and to have them in separate *organisations* is pretty much unique to
    the root zone - where we certainly don't have to worry about how to
    update the DS records in the parent zone :-)

---

From: Stephen Morris <[email-masked]>
Date: Fri, 08 Jul 2011 19:03:41 +0100

On 30/06/2011 23:33, George Barwood wrote:

> Is the earlier requirements draft from 2005 (linked above) substantially incomplete in some way?
> I think that would be a reasonable basis to measure, I would claim that the CDS
> record is capable of satisfying the requirements expressed there in a natural way. 
> I also think the requirement is actually fairly clear - when implementing KSK rollover,
> you reach a point where it's clear that something is needed ( other than asking
> the operator to start cutting and pasting / interfacing with some out-of-band system / whatever).
> I doubt another cycle of requirements would be productive - we might be here again in 6 years time!

I think Olafur summarised it quite succinctly:

"So maybe we should be having a different discussion:
Does DNSSEC obsolete updating NS and DS information via EPP/Web/Email ?"

If the answer is yes, then the CDS approach is certainly one to be
looked at.  The answer also suggests that we should be looking at an
equivalent mechanism for updating NS (and possibly glue) information in
the parent zone.  Perhaps all can be done under a single framework?

If the answer is no, then along with publishing a mechanism for the
automatic update of DS records, should we be providing guidance on when
to use that and when to use EPP/Web/Email?

Don't get me wrong, I don't want any unnecessary delay.  But if it turns
out that what is being addressed is part of a larger problem, it's worth
looking first to see if there is a general solution.

Stephen

---

From: Joe Abley <[email-masked]>
Date: Fri, 8 Jul 2011 17:18:44 -0400

> the parent zone.  Perhaps all can be done under a single framework?

If that's the direction we're looking in, then delegation scaffolding (NS and DS) seems like just the beginning; perhaps we need to consider the possibility of zone managers pushing signed registry ("whois") metadata from the DNS back into the registry as well. I'm not convinced that's sensible, but it seems helpful to find out how deep the rabbit hole goes if we want to properly scope the problem space.

A zone -> registry data flow might at least provide some incentive for DNSSEC deployment, if it represented a simplification for the registry interaction required by DNS service providers.

On the other hand, if this is an effect a short-cut between registry and registrant (or by the registrant's agent, in the case of third-party signing/hosting of zones) then we might discover that it's contractually infeasible for any gTLD registry to support.

> looking first to see if there is a general solution.

+1

Joe

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 08 Jul 2011 18:23:33 -0400

> If that's the direction we're looking in, then delegation scaffolding (NS and DS) seems like just the beginning; perhaps we need to consider the possibility of zone managers pushing signed registry…

Just let Whois die a peaceful death, it serves no purpose other than 
make work.
> On the other hand, if this is an effect a short-cut between registry and registrant (or by the registrant's agent, in the case of third-party signing/hosting of zones) then we might discover that i…

As I mentioned in my prior post to dnsop,
Parent != Registry in the RRR world.

There is no reason why the registrar can not perform this "scan"
and update the registration information.
The biggest beneficiary in the RRR world is the external DNS operator 
that currently has to funnel DNS information via the registrant.

>> looking first to see if there is a general solution.
+1
IMHO this is a no-brainer once we agree on few constraints:
	a) only applies to normal changes
	b) delay of few days/weeks is acceptable

Thus:
	New registration is not covered.
	Emergency operations are not supported
	Transfer is not explicitly supported, but at the same time not prevented.

	Olafur

---

From: Joe Abley <[email-masked]>
Date: Fri, 8 Jul 2011 19:40:18 -0400

On 2011-07-08, at 18:23, Olafur Gudmundsson wrote:

> Just let Whois die a peaceful death, it serves no purpose other than make work.

Other people are working on the death of whois; I was just trying to clarify the type of data I was talking about.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Jul 2011 11:05:39 -0400

>looking first to see if there is a general solution.

I sent a response to the chairs and to George earlier because, and 
I'll explain, I've been purposely ignoring the CDS proposal.  After a 
quick back and forth, I figured I should post to the list.

I have been ignoring CDS because both of the angles I have on DNS 
would find record to be useless.  I do not feel it is worthwhile to 
suppress work in the IETF that is of no consequence, so I haven't 
objected.

My angles include ICANN contracted TLD operator and a managed DNS 
provider.  In the former, we have to address the Shared Registry 
Model whether it is universal or not.  As a managed DNS provider, we 
don't have to beckon to the SRM but the (what I estimate to be) vast 
majority of our customers do.

I understand that my angles are not the only ones.  There are 
situations in which an direct parent-child exchange of information 
makes sense.  But it doesn't for me and doesn't for, I'll put it this 
way, a significant portion of the domain name management market.

A snide person would ask "does the IETF want to invent cool gadgets 
or useful gadgets?"  Cool would be something that is direct, useful 
is something that is acceptable to the SRM.

One more caveat.  It's not an open-and-shut case that CDS would be 
"in violation" of the SRM.  Perhaps a direct parent-child solution 
could be hammered out.  But given other priorities, I just have spent 
any time on CDS because I think it is unlikely.

I don't believe we need a single, one-size fits all solution.  I 
think that sometimes that goal is a huge deterrent in finding a 
workable set of solutions.

These are two questions asked in a side conversation and figured I 
might as reply on the list.

>(a) if a child zone requests through the proper channels that its DS
>record in the parent be updated, under what circumstances would the
>parent refuse the update?

Authorization checks failing.  I don't have specifics, but 
conventional wisdom holds that if a registrar tries to designate a 
dns operator with a registry, things still don't work so well. 
Perhaps it's an industry legend, but I think there are folks 
reluctant to try this.

>(b) could publication of a CDS record in a signed child zone constitute
>an authorised request?

I kind of doubt that the practice would be accepted widely.

There's a wide array of concerns in running registries.  In some, 
tracking transactions is one, so that any changes can be audited.  In 
these, one would pretty much be forced to funnel all requests into 
one channel for tagging.  Out of band communications (relative to the 
registry) would be discouraged.

What I've posted are general, fuzzy, hand-waving reasons why CDS 
wouldn't be a general solution.  Arguing the other way, that CDS 
would be general, is like arguing a negative which is fraught with 
logic problems.  This is why I wouldn't fight "against" CDS but just 
won't dedicate time to examine it closely.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.