Subject: [DNSOP] Fwd: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Feb 2013 17:35:58 -0500

Hi all,

This is a compilation of two earlier drafts, draft-barwood-dnsop-ds-publish and draft-wkumari-dnsop-ezkeyroll.

The basic idea remains the same -- allow operators to publish new (and standby) DS records at the parent by publishing them in their zone, signed with their current key.

This new draft explains the problem a little better, and also that, in the "registries shouldn't talk to registrars" model the registrar can do the magic instead.

We believe that there is a need / desire for this -- apart from the fact that *I* hate having to click all over the GoDaddy web site to change keys, we have heard a number of registrars and registrars asking for it...

W

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt
> Date: February 18, 2013 4:06:00 PM EST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> 
> 
> A new version of I-D, draft-kumari-ogud-dnsop-cds-00.txt
> has been successfully submitted by Warren Kumari and posted to the
> IETF repository.
> 
> Filename:	 draft-kumari-ogud-dnsop-cds
> Revision:	 00
> Title:		 Easy DNSSEC Key Publish
> Creation date:	 2013-02-18
> Group:		 Individual Submission
> Number of pages: 8
> URL:             http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
> Htmlized:        http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-00
> 
> 
> Abstract:
>   This document describes a method to allow DNS operators to more
>   easily publish updated DNSSEC Key Signing Keys.  This document does
>   not address the initial configuration of trust anchors for a domain.
> 
> 
> 
> 
> The IETF Secretariat
> 

--
Life is a concentration camp.  You're stuck here and there's no way out and you can only rage impotently against your persecutors.
                -- Woody Allen

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Mon, 18 Feb 2013 17:05:21 -0700

Warren Kumari, Monday, February 18, 2013 4:36 PM:
> Hi all,
> 
> This is a compilation of two earlier drafts, draft-barwood-dnsop-ds-
> publish and draft-wkumari-dnsop-ezkeyroll.
>
> The basic idea remains the same -- allow operators to publish new (and
> standby) DS records at the parent by publishing them in their zone,
> signed with their current key.
> 
> This new draft explains the problem a little better, and also that, in
> the "registries shouldn't talk to registrars" model the registrar can
> do the magic instead.

I support this effort and think it would be very useful. However there
are a few areas that I think needs additional work. I think you need to
better explain how old DS records are removed.  Would it be possible to
make the 'going unsigned' method more granular so that you can use it to
specify individual DS records?

Thanks, Stephan

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 18 Feb 2013 20:30:32 -0500

> specify individual DS records?

Stephan,
Basically the @parental agent@ copies the contents of the CDS RRset
and replaces the existing DS set with the new one. .
So if you want to delete a particular DS record you remove it from the 
CDS set.
Going Unsigned is to delete all the DS records no exceptions, we can not 
use No CDS present as the semantics of that state is no changes to 
current DS set.

	Olafur

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Feb 2013 11:07:14 -0500 (EST)

> The basic idea remains the same -- allow operators to publish new (and standby) DS records at the parent by publishing them in their zone, signed with their current key.

I of course hope this draft or something similar will go through. The
fact that the older CDS draft got stuck was for me the motivation
behind draft-wouters-dnsop-secure-update-use-cases but that seems
stalled by people being ver nervous about the RRR model. I had to
carefully not mention any technology I prefered in that draft, but
this kind of mechanism always had my preference, as it requires no
direct parent-child port 53 access, and signaling between parent
and child an be done my helpers that are not in the actual path of
serving DNS data, so it is also the most secure method of doing it.

What is missing in this draft doing the same for other parent-child
data, such as NS and glue records. Since we have an authenticated
parent-child relationship now, why not extend this draft to include
CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here, because
the mechanism will be basically identical, although perhaps some more
prevention for shooting one's foot might be required.

    In many environments (for example, gTLDs) the parent will be a
    registry, and is expected to not have direct contact with the child
    (registrant).

I recommend removing ANY kind of language that ties anything to the RRR
model, as just mentioning it is what more or less killed the use-cases
draft. That includes mentioning TLDs or "Registry interface".  Specify the
protocol, leave out the administration/politics and don't tell people
how to integrate the implementation.

 	In this case the parental agent will query each child zone that has a
 	DS RRset, looking for CDS RRset

That's a good mechanism to leave the initial auth specification (tied to
RRR or not) out of the spec! Bravo!

 	If the validation succeeds with a DNSKEY that is represented
 	in the current DS RRset in parent.

You have to be more strict then just "validation succeeds". You MUST
ensure the proper DNSKEY's matching the CDS records exist on ALL
secondary servers, and must wait AT LEAST a TTL time before being
willing to update the DS record.

 	The parenteral agent should
 	submit a request to the registry to publish the contents of the CDS
 	RR(s) as the new a DS record(s) for that zone.

But here you go wrong. Rewrite it to not mention "registry". Just talk
about the parent zone manager. You could be talking about an inline
bind, a cron job, some perl code, a database ...whatever the parent is.

 	The registry should log if possible the source of the update,
 	user interface/CDS etc.

Same here.

 	IN CDS 0 0 0

I really dislike this idea. An attacker that has no access to the keys,
but does have access to unsigned zone data could put such a record in
the zone to fully remove the security added by the DNSSEC signer to
which they might not have access (yet). This can cause an escalation
from "needing a still-compromised server" to "only need to compromise a
server briefly and then leave without a trace".

I believe you should stick to out of band communication for both secure->
insecure and insecure -> secure.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 19 Feb 2013 08:36:49 -0800

> prevention for shooting one's foot might be required.

+1. The operational implications of NS record changes are the same as for DS, even though the DNS protocol ramifications are different.

And, before someone suggests it, I am *not* in favor of a kitchen-sink approach that defines some record of a random type as being for the parent. It is fine for us to specify as many of these records now that we know about (DS and NS and glue being mentioned so far), and if someone comes up with one later, they can update the RFC with a new type for the new record.

--Paul Hoffman

---

From: Jacques Latour <[email-masked]>
Date: Tue, 19 Feb 2013 12:20:19 -0500

Another "what if scenario" for bypassing the EPP keyrelay with automation, what if there was a CKEYRELAY record pointing to the gaining DNS operator name servers, where the parent zone operator can grab the new DS record to be pre-published prior DNS operator transfer? 

Potentially, parent zone can manage add/delete/transfers automatically, except for the initial DNSSEC setup which needs to be authenticated.

Jack
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Hoffman
> Sent: February-19-13 11:37 AM
> To: [email-masked] WG
> Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-
> dnsop-cds-00.txt
> 
> > CNS/GLUEA/GLUEAAAA ? To me it makes sense to integrate it here,
> > because the mechanism will be basically identical, although perhaps
> > some more prevention for shooting one's foot might be required.
> 
> +1. The operational implications of NS record changes are the same as for DS,
> even though the DNS protocol ramifications are different.
> 
> And, before someone suggests it, I am *not* in favor of a kitchen-sink
> approach that defines some record of a random type as being for the parent.
> It is fine for us to specify as many of these records now that we know about
> (DS and NS and glue being mentioned so far), and if someone comes up with
> one later, they can update the RFC with a new type for the new record.
> 
> --Paul Hoffman

---

From: Marc Lampo <[email-masked]>
Date: Tue, 19 Feb 2013 20:50:41 +0100

Hello,

a couple of constructive remarks :
1) Should the CDS RR have the same fields as the DS ?
    Or : is there any benefit in adding a field with some "operation
code" (failing a better name)

    Suppose a code is added :
    0 could mean : corresponding KSK created - this will be the DS -
don't publish yet
    1 could mean : I'm hold data for a DS to be published
    2 could mean : IKSK is retiring - no longer publish this data in a DS

    Might help for troubleshooting :
    like - why is the DS no longer there --> look at CDS records.
    In the present draft : no CDS records <-> no corresponding DS (but
there is no history info)

    Also, the present draft suggest "@ IN CDS 0 0 0" to go unsigned.
    But the situation where "@ IN CDS 0 0 0" appearrs *together* with
another CDS that does hold data is not described.
    If there will be no "operation code", handling of above error case
should be in the draft, I think.

2) "SIgned with a DNSKEY that has the SEP bit flag set" ?
    Why ?

    If there is chain-of-trust up till and including the ZSK of the zone,
    why not "trust" that information.

    On one side : some name server implementations use KSK's only to
sign DNSKEY RRset's.
    It requires extra arguments or change in the code to consider CDS's as well.

    On the other side : would it be an error to publish 2 KSK's, but
sign CDS RRset with only one of them ?

    I think this point needs more motivation - or there should be no
insisting on signing with KSK's.

3) Periodic check by parental agent

   I think this should be extended by stating that logging of "somehow
rejected" CDS RRset should be done.
   At what time,
    from with authoritative NS,
    wich CDS RRset received
    and why it was not used for publishing.

4) Should the parental agent check all authoritative name servers of a
domain for a consistent CDS RRset ?

    Perhaps just mention, in the draft, what the expected behavior is.
    I remember from previous contributions I made - while still at a
top-level-domain myself -
    that some reactions might/will be : "not our responsibility".
    I'm OK with that, but I'd suggest the draft states what is to be expected.

5) (this is tricky !) Security section states : "not for initial enrollment"
    Why not ?

    If it is "not our responsibility" (if a DNS operator messes up the
signed zone) anyway,
    why not "detect" the presence of :
    DNSKEY RRset
    valid RRsig's
    CDS RRset (properly signed with a published DNSKEY)
      (for validation, use the DNSKEY the RRSIG refers to, "believe"
it without chain-of-trust being in place)
    (if there is no CDS RRset - or there is with some "operation code" == 0,
     then, don't publish)

    This would overcome the initial 12 steps to bootstrap a zone with DNSSEC.

6) Please correct the address of author George Barwood
    (or you get too much email, Warren ;-)

Kind regards,

Marc

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Feb 2013 16:00:28 -0500 (EST)

> there is no history info)

I don't think these are worth the complexity.

>    why not "trust" that information.

Because ZSK might be online, and KSK might be offline. It should come
from the KSK, not the ZSK, or else the ZSK can change an offline KSK.

>    and why it was not used for publishing.

IMHO, al ofthat is implementation and does not belong in a protocol
specification.

> domain for a consistent CDS RRset ?

Yes, as I said in my previous email.

> 5) (this is tricky !) Security section states : "not for initial enrollment"

There is no path of trust!

Paul

---

From: Scott Rose <[email-masked]>
Date: Wed, 20 Feb 2013 13:54:39 -0500

> There is no path of trust!

+1, I think the draft should keep the recommendation that this is not for initial enrollment.  

One other comment in Section 5.1, last paragraph:  If the child zone does go unsigned, the parental agent should not (or SHOULD NOT) treat that as intent to go unsigned since that could be an attack.  An attacker could spoof unsigned responses to queries from the parental agent in an attempt to force a break in the DNSSEC chain.  We had this discussion on how to respond to signed .gov zones that erred and stripped their own RRSIGs/DNSKEYs.  

Minor quip:
Section 4: 'It is conceivable that this could be a "value added" service"'  Really doesn't belong in a protocol spec and really doesn't add anything.  Suggest dropping it. Registrars/service providers can figure that out on their own (if they haven't already). 

Scott

> Paul

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

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 25 Feb 2013 11:03:13 +0100

Op 19-02-13 18:20, Jacques Latour schreef:
> Another "what if scenario" for bypassing the EPP keyrelay with
> automation, what if there was a CKEYRELAY record pointing to the
> gaining DNS operator name servers, where the parent zone operator
> can grab the new DS record to be pre-published prior DNS operator
> transfer?

This does not work as there is no chain of trust yet to the gaining
DNS operator. This proposal only works when changes are made that are
in the current chain of trust with the current DNS operator. The
challenge with EPP keyrelay is to get the key from the gaining dns
operator delivered to the current operator so that it becomes a second
chain of trust after it is inserted in the current delegated zone.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 25 Feb 2013 16:50:03 -0500

I just posted a new version:
http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-01.txt

> prevention for shooting one's foot might be required.

In new version this will be hinted at but not explained to constrain scope.

> how to integrate the implementation.

Well the new version has more text not less but hopefully as it all 
examples this will not cause problems.

> willing to update the DS record.

New version says:
           If present the Parental Agent MUST validate [<xref
           target="RFC4035"></xref>] the CDS RRset. If the validation 
succeeds
           with a DNSKEY that is represented in the current DS RRset in 
parent.

Hope that is strong enough

> bind, a cron job, some perl code, a database ...whatever the parent is.

Attempted to fix this.

> server briefly and then leave without a trace".

If they have that access what stops them then from publishing anything 
in the zone, including forged DNAME records?

> insecure and insecure -> secure.
thanks for the good comments.

	Olafur

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Feb 2013 17:27:58 -0500 (EST)

On Mon, 25 Feb 2013, Olafur Gudmundsson wrote:

>          target="RFC4035"></xref>] the CDS RRset. If the validation succeeds

I'm not sure. I don't see RFC 4035 talking about what a recursor should
do when it needs to find DNSKEY x1 and it contacts a (random) child name
server and x1 is not there. Is that a bogus response, or will it try the
other child name servers in an attempt to find the x1 DNSKEY?

I think for a name server to roll its DS for the child, it should really
ensure the CDS records point to DNSKEYs that have been available in the
child zone for TTL(DNSKEY) time on _all_ child zone name servers.

This might be different from the "regular" policy of DNSSEC capable
resolvers.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 26 Feb 2013 10:03:16 -0500

> other child name servers in an attempt to find the x1 DNSKEY?

local policy for each validator implementation possibly configurable and 
possibly
affected on what is observed, the general principle is "If it validates: 
done"
in your example it is not clear if the DNSKEY RRset validates
     but is missing the key you are looking for.
     or if you expect the set to be validated by key x1.
> child zone for TTL(DNSKEY) time on _all_ child zone name servers.
I realized that while we can add that as guidance there is a missing 
part of the rule in the draft:
The Parental Agent MUST/SHOULD make sure that replacing the DS with the 
CDS will not break the
delegation. (Principle: Child can shoot itself in the foot but Parent 
should avoid to harm Child)

     Olafur

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Feb 2013 14:56:25 +0800

Having quickly read the -01 for Automating DNSSEC delegation trust maintenance:

I'd like to propose a twist.  Comparing to X.509, a CDS record is kinda sorta like a key signing request.  For that reason I want to see an explicit "request" in the RDATA and not have anything implied.

I would suggest that the RDATA of it *not* be the same as the DS record.  There should be an explicit RDATA element instructing the parent what to do with the request.  Probably some other ancillary data will be needed too.

I would not specify how the parent "discovers" the CDS.  Just as for AXFR, knowing how AXFR works is different from why it is called.  I say this because in some scenarios I can see the parent scanning the children and in others there will be an event driven reason to look for the CDS set at a child.  In some cases "scraping" is optimal, in some cases "explicit" is optimal.

The CDS has to do this:

1. Let the parent know whether it is a request for new DS records or whether this is a request to delete DS records.  (Plural referring to the fact that a SEP might have more than one DS record.)

2. Let the parent know when this request was first posted (so that the parent can tell if it did this one before).  I.e., a 32 bit timestamp viewed as a yyymm-etc. like the RRSIGs do.  Or it could be the serial number of the zone when the request was added (although that might be hard for a tool to determine).  But - goal is - something to let the parent know when this request appeared so that the parent can guess whether it has already responded to it.

3. Let the parent know the RDATA of the DS records that are desired.

What #3 hints at is the case where DS records are requested for a DNSKEY that is not (yet) published in the child zone.  There is a DS record in the root zone for a ccTLD that points to no existing record - an example that this is done.

I'd like to see one CDS per DNSKEY state change.  It is up to the child to groom the CDS set, that is, once the parent has granted the request (which can be seen by asking the parent) the child has the onus to remove the CDS - but as protocol designers we have to account for the case where a child does not remove a CDS (ever), and might in fact have a CDS to add a key and another to delete the key.

Other considerations.  I left off "urgent" or "due time" because those features generally are overkill.  For urgent matters, that falls under the "why" category  and not the "how" category.  And "how" is what we need to define.

For example, a zone has KSKs with footprints/ids of 11111 and 22222 and is flipping to the latter:

zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1 DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7

The hash in the DELETE is over kill.  Perhaps for that just the footprint is needed (unless you want to delete one or the other hash only).

Here's a meltdown case that I want to smooth over (with hashes elided):

zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ...
zone.tld.   1800  IN  CDS   DELETE 20130301000000 22222 ...

In this case, the child forgot to remove the add request when it decided to do the delete.  (No intention of allowing the timestamp to be a schedule - even though I show a future date in the example, I did that just for convenience.)  The parent should know then to delete what it has for 22222, whether or not it ever added the DS.  (E.g., if the two records popped up together with the same timestamp.)

PS - looking at the email addresses for the authors: so it is true, Warren and George are the same person!

---

From: Marc Lampo <[email-masked]>
Date: Thu, 28 Feb 2013 08:23:05 +0100

Hello,

somewhat more words but in line with what I was suggesting, a couple
of days ago,
about adding "operation code" to CDS RDATA.

This still feel like a good idea, worth elaborating, I'd see.
I support this.

Kind regards,

Marc Lampo

On Thu, Feb 28, 2013 at 7:56 AM, Edward Lewis <[email-masked]> wrote:
> I'd like to propose a twist.  Comparing to X.509, a CDS record is kinda
> sorta like a key signing request.  For that reason I want to see an explicit
> "request" in the RDATA and not have anything implied.
>
> I would suggest that the RDATA of it *not* be the same as the DS record.
> There should be an explicit RDATA element instructing the parent what to do
> with the request.  Probably some other ancillary data will be needed too.
>
> I would not specify how the parent "discovers" the CDS.  Just as for AXFR,
> knowing how AXFR works is different from why it is called.  I say this
> because in some scenarios I can see the parent scanning the children and in
> others there will be an event driven reason to look for the CDS set at a
> child.  In some cases "scraping" is optimal, in some cases "explicit" is
> optimal.
>
> The CDS has to do this:
>
> 1. Let the parent know whether it is a request for new DS records or whether
> this is a request to delete DS records.  (Plural referring to the fact that
> a SEP might have more than one DS record.)
>
> 2. Let the parent know when this request was first posted (so that the
> parent can tell if it did this one before).  I.e., a 32 bit timestamp viewed
> as a yyymm-etc. like the RRSIGs do.  Or it could be the serial number of the
> zone when the request was added (although that might be hard for a tool to
> determine).  But - goal is - something to let the parent know when this
> request appeared so that the parent can guess whether it has already
> responded to it.
>
> What #3 hints at is the case where DS records are requested for a DNSKEY
> that is not (yet) published in the child zone.  There is a DS record in the
> root zone for a ccTLD that points to no existing record - an example that
> this is done.
>
> I'd like to see one CDS per DNSKEY state change.  It is up to the child to
> groom the CDS set, that is, once the parent has granted the request (which
> can be seen by asking the parent) the child has the onus to remove the CDS -
> but as protocol designers we have to account for the case where a child does
> not remove a CDS (ever), and might in fact have a CDS to add a key and
> another to delete the key.
>
> Other considerations.  I left off "urgent" or "due time" because those
> features generally are overkill.  For urgent matters, that falls under the
> "why" category  and not the "how" category.  And "how" is what we need to
> define.
>
> zone.tld.   1800  IN  CDS   DELETE 20130201000000 11111 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 1
> DFB91171CF0FB1DC48B2CEB8DD9A173CC1A28E55 2
> 4052E3B1BF483C993C018AA3513065A61E7FE842C60C03F44B0ACCFFE011E0A7
>
> The hash in the DELETE is over kill.  Perhaps for that just the footprint is
> needed (unless you want to delete one or the other hash only).
>
> In this case, the child forgot to remove the add request when it decided to
> do the delete.  (No intention of allowing the timestamp to be a schedule -
> even though I show a future date in the example, I did that just for
> convenience.)  The parent should know then to delete what it has for 22222,
> whether or not it ever added the DS.  (E.g., if the two records popped up
> together with the same timestamp.)
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Feb 2013 16:11:02 +0800

Ahh, yes.  I went back to see your message.

I'll address the points in your message here

1)  Telling the parent "this is a new KSK and it will have a DS in the future" (code 0) is unnecessary.  This is state the parent should not track and not have the burden of tracking.  The other two states map to my "ADD" and "DELETE" but in mine I hide semantics (or reasons why).  So for the most part we agree.

2) All that is needed is the CDS be signed as any other RRSET.  When the parent elects to do so, it would do a query +DO to get the records and hope to see "ad" in the flags.

3) I don't think the parent ought to have to do a periodic check (it's up to the parent).  Either way, that doesn't belong in the document.

4) Good question - I would assume that a well-run zone would have in-sync servers.  Given that the document assumes the parent could "scrape" this, the concern is understood.  But my assumption is that this would be event driven (prompt up the tree somehow) and that lessens the concern of an out of sync server.  OTOH, I have the idea that there needs to be some way of tagging the request to get it's freshness. OYTOH (On yet the third hand), there's always out of band ways to ask for a retry.

5) Kind of agree - why not.  If the domain name is registered via a method that has a half-dozen pre-delegation checks and credit checks, what more armoring is needed?

6) Ahh, and I thought I was the only one that noticed.  (Sorry, Marc, evidently I hadn't read all of your message. ;))

What I have in mind is a smaller definition for CDS, but use it in a way where the client has the responsibility to check whether the parent has granted the request.

>> and George are the same person!

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

There are no answers - just tradeoffs, decisions, and responses.

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Feb 2013 11:43:35 +0000

Edward Lewis <[email-masked]> wrote:
>
> Let the parent know when this request was first posted (so that the
> parent can tell if it did this one before).

The update logic ought to be idempotent, i.e. the instructions from the
child should be of the form "make it look like this" not "perform this
action". Then the parent needs no state other than the CDS RRset and the
DS RRset.

It might be desirable to be able to say "like this before such-and-such a
time, and like that afterwards". So maybe CDS RRs need inception and
expiry dates?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Feb 2013 08:49:03 -0500 (EST)

> time, and like that afterwards". So maybe CDS RRs need inception and

But that seems to be local policy of the parent. Not something the child
should have any say over?

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 28 Feb 2013 14:26:42 +0000

> should have any say over?

You are probably right.

The ideal is for the admin to trigger a key rollover and the rest happens
automatically. The scheduling idea (above) is sort of based on exposing
BIND's key timing parameters (dnssec-settime) so that the parent can
follow along. But this requires quite a lot of faith that the parent will
actually follow along as requested, so it probably isn't robust enough.

So whatever is co-ordinating the key rollover at the child needs to
monitor the parent to see when the DS RRset changes so that the rest of
the schedule can be adjusted accordingly. And if you are doing that, you
might as well alter the CDS RRset like you do with the DNSKEY RRset, and
wait for the parent to notice and act on the change.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Feb 2013 13:29:16 -0500 (EST)

> wait for the parent to notice and act on the change.

I'm just trying to avoid another round of "Triggers vs Timers" :)

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 28 Feb 2013 18:02:26 -0500

Ed,

Thank you for your review from the "parent perspective".

CDS is designed to be as simple as possible to operate for both parents 
and child.
CDS is designed around the "Replace" operation, you and Marc are
proposing to change that to Add/Delete operations.

In the draft a Parental Agent can simply sort and compare
	the RDATA of CD to the RDATA of CDS
if there is a difference it can either
	- figure out the diff and translate that to ADD/DELETE actions
	- or simply say "Delete <foo> DS *; Add <foo> DS ...."

Yes I can envision a tool that looks a the "proposed DS" in a file at
child compares to current DS and creates "CDS action records"
as you propose and then takes these actions out after the parent
reflects the update.

It think this discussion broils where does the complexity lives and if
the different choices make life significantly simpler for one party or
the other.

I'm not sure that the ADD/DELETE model is simpler for the parent as in
both cases the Parental Agent needs to check some "back end" as when it
last performed an action for the Child and or if the action is redundant.

Thus before we go into discussion into details of record formats, lets
have the REPLACE vs ADD/DELETE discussion.

	Olafur

On 28/02/2013 01:56, Edward Lewis wrote:
> I'd like to propose a twist.  Comparing to X.509, a CDS record is
> kinda sorta like a key signing request.  For that reason I want to
> see an explicit "request" in the RDATA and not have anything
> implied.
>
> I would suggest that the RDATA of it *not* be the same as the DS
> record. There should be an explicit RDATA element instructing the
> parent what to do with the request.  Probably some other ancillary
> data will be needed too.
>
> I would not specify how the parent "discovers" the CDS.  Just as for
>  AXFR, knowing how AXFR works is different from why it is called.  I
>  say this because in some scenarios I can see the parent scanning the
>  children and in others there will be an event driven reason to look
>  for the CDS set at a child.  In some cases "scraping" is optimal, in
>  some cases "explicit" is optimal.
>
> The CDS has to do this:
>
> 1. Let the parent know whether it is a request for new DS records or
>  whether this is a request to delete DS records.  (Plural referring
> to the fact that a SEP might have more than one DS record.)
>
> 2. Let the parent know when this request was first posted (so that
> the parent can tell if it did this one before).  I.e., a 32 bit
> timestamp viewed as a yyymm-etc. like the RRSIGs do.  Or it could be
>  the serial number of the zone when the request was added (although
> that might be hard for a tool to determine).  But - goal is -
> something to let the parent know when this request appeared so that
> the parent can guess whether it has already responded to it.
>
> What #3 hints at is the case where DS records are requested for a
> DNSKEY that is not (yet) published in the child zone.  There is a DS
>  record in the root zone for a ccTLD that points to no existing
> record - an example that this is done.
>
> I'd like to see one CDS per DNSKEY state change.  It is up to the
> child to groom the CDS set, that is, once the parent has granted the
>  request (which can be seen by asking the parent) the child has the
> onus to remove the CDS - but as protocol designers we have to account
> for the case where a child does not remove a CDS (ever), and might in
> fact have a CDS to add a key and another to delete the key.
>
> Other considerations.  I left off "urgent" or "due time" because
> those features generally are overkill.  For urgent matters, that
> falls under the "why" category  and not the "how" category.  And
> "how" is what we need to define.
>
> The hash in the DELETE is over kill.  Perhaps for that just the
> footprint is needed (unless you want to delete one or the other hash
>  only).
>
> zone.tld.   1800  IN  CDS   ADD 20130201000000 22222 7 ... zone.tld.
>  1800  IN  CDS   DELETE 20130301000000 22222 ...
>
> In this case, the child forgot to remove the add request when it
> decided to do the delete.  (No intention of allowing the timestamp to
> be a schedule - even though I show a future date in the example, I
> did that just for convenience.)  The parent should know then to
> delete what it has for 22222, whether or not it ever added the DS.
> (E.g., if the two records popped up together with the same
> timestamp.)
>

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Mar 2013 09:37:04 +0800

> action". Then the parent needs no state other than the CDS RRset and the

I'd considered that.  My experience is that this goal is admirable but can cause a request to become large in size and hard to understand.

I'm hoping to avoid yet another too-large RRset that could cause problems in abuse situations.  And we do have an interested party here, the client, that should have already automated the KSK change event.

> time, and like that afterwards". So maybe CDS RRs need inception and

Oh, great scott no!

Sigh, sorry.  I spent many years (in the 90's) playing with the semantics of having RRSIGs for a set with varying spans of validity.  It's a waste!

Note - my assumption is that I'll layer over the CDS a tool that will manage the key roll and that tool will be managed by some sort of calendar.  Part of this maps to what I've seen in an open source DNS product that will allow users to schedule key changes now.

(Poorly worded way of saying - given how I've seen changes happen in operator settings, I think embedding times and trying to be idempotent detract from the experience.  Again, this is opinion, not based on factual logic.)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Mar 2013 10:30:47 +0800

I had sent a more detailed off-list reply, but I should address this:

> have the REPLACE vs ADD/DELETE discussion.

My starting assumption is that the CDS will be a tool used inside a script or procedure (which may already exist in operating zones) that performs the change of the SEP.  These tools vary by operator because of the myriad of combinations of requirements in place.

In my opinion, for the CDS to be useful in all of the various environments if has to avoid getting beyond the most basic primitives.  No assumption that the adds and deletes are parts of a replace, no expression of timing, no expression of any other policy-like thing.

Leave the semantics to the scripts and policies already in place.  Even if you just do that, CDS cuts down on having to transport the keying material via something like cut and paste from a dig or web page to a web form.  (To use the situation I have most in mind.)