Subject: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-01.txt

From: [email-masked]
Date: Sat, 04 Jan 2014 12:40:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Automating DNSSEC delegation trust maintenance
        Authors         : Warren Kumari
                          Olafur Gudmundsson
                          George Barwood
	Filename        : draft-ietf-dnsop-delegation-trust-maintainance-01.txt
	Pages           : 17
	Date            : 2014-01-04

Abstract:
   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using DNS as communication
   channel.  This document does not address the initial configuration of
   trust anchors for a domain.  The technique described is aimed at
   delegations in which it is currently hard to move information from
   the child to parent.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Warren Kumari <[email-masked]>
Date: Sat, 4 Jan 2014 16:21:03 -0500

We think that this resolves the open comments and is ready for WGLC.

On Sat, Jan 4, 2014 at 3:40 PM, <[email-masked]> wrote:

>         Filename        :
> draft-ietf-dnsop-delegation-trust-maintainance-01.txt
>         Pages           : 17
>         Date            : 2014-01-04
>
> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 5 Jan 2014 05:20:45 +0530

Hi Warren

> We think that this resolves the open comments and is ready for WGLC.

Here are some comments:

Section 1
---------

> CDS only allows transferring information about DNSSEC keys (DS and
> DNSKEY) from the child to the parental agent.  It lists exactly what

"CDS" is used without any prior description of it.

Section 1.1
-----------

Use of punctuation in this section can be improved.

> There terminology we use is defined in this section

"There terminology..." => "The terminology...".

Section 2.1
-----------

When mentioning RRtypes (NS, DS, etc.), it would be good to cite the
relevant RFCs where they were introduced.

> The second RRset the parent sometimes publishes is the DS set.  The
> DS RRset provides information about the key(s) that the child has
> told the parent it will use to sign its DNSKEY RRset.  In DNSSEC

May I suggest changing "keys(s)" => "DNSKEY(s)"?

> As the DS record can only be present at the parent RFC4034 [RFC4034],
> some other record/method is needed to automate the expression of what
> the parental zone DS records contents ought to be.  One possibility
> is to use flags in the DNSKEY record.  If the SEP bit is set, this

I suggest rewriting this sentence:

"As the DS record can only be present at the parent RFC4034 [RFC4034],
some method is needed to automate which DNSKEYs are picked to be
represented in the parent zone's DS records."

A sentence explaining why a method is needed to automate locating entry
point keys would be good to have here.

> indicates that the DNSKEY is intended for use as a secure entry
> point.  This DNSKEY signs the DNSKEY RRset, and the Parental Agent
> can calculate DS records based on that.  But this fails to meet some
> operating needs, including the child having no influence what DS

Does this mean that the Parental Agent automatically picks up DNSKEY RRs
with SEP=1 from the child zone? (How are these DNSKEYs validated?) This
should be explained.

> digest algorithms are used and DS records can only be published for
> keys that are in the DNSKEY RRset.

Does this imply use of additionally configured trust anchors when such
keys are not in the DNSKEY RRset? Such minor clues are useful when
reading.

Section 2.2
-----------

>                                        ... in which an organization
> may delegate parts of its name-space to be operated by a group that
> is not the same as that which operates the enterprise's DNS servers.

Do "organization" and "enterprise" in the trimmed context above refer to
the same entity? If the word "enterprise" covers all organizations,
"enterprise's DNS servers" seems to mean one particular organization's
DNS servers.

I was not able to follow this paragraph (though I follow what is
intended to be described).

Section 2.2.1
-------------

> A further complication is when the Child DNS Operation is not the
> Child.  There are two common cases of this,

"Child DNS Operation" => "Child DNS operator"

>   If the Parental Agent is the DNS operator, life is much easier, as
>   the Parental Agent can inject any delegation changes directly into
>   the Parents Provisioning system.  The techniques described below are
>   not needed in the case when Parental Agent is the DNS operator.

"Parents Provisioning system" => "Parent's Provisioning system"

>   Some parents want the child to express the changes in trust anchors
>   via DS records, while others want to receive DNSKEY records and

Is "trust anchor" used according to its definition here? Specifically it
pertains to a resolver's configuration. There is a similar use of "trust
anchor" in the abstract too.

> interface, to "upload / paste-in the zone's DS information".  The
> action of logging in through the delegation account user interface
> authenticates that the user is authorized to change delegation
> information published in the parent zone.  In the case where the

"... change delegation information *for the child* published in the
parent zone." (i.e., not all delegation information in the parent zone.)

> Furthermore when this is a manual process with cut and paste;
> operational mistakes will happen. Or worse the update action in not
> performed at all.

Please replace the above with the following (punctuation and typo
changes):

"Furthermore when this is a manual process with cut and paste,
operational mistakes will happen, or worse, the update action is not
performed at all."

Section 3
---------

> This document specifies two new DNS RRtypes (CDS and CDNSKEY) that
> indicates what the Child wants to be in the parents DS RRset.  It

Instead of "to be in the", I suggest something like:

"... what the Child wants to be included in the parent's DS RRset."

"... what the Child wants the parent's DS RRset to contain."

(also note the apostrophe in "parent's").

> allows the Child to present DS records and / or DNSKEY records (for
> those parents who would rather generate the DS records for their
> children).

> [RFC Editor: Please remove this paragraph before publication] Version
> -04 of this document defined a new record (CTA) that could hold
>  either a DS or a DNSKEY record (with a selector to differentiate
>  between them). ]

Where is version -04 of this document? What is this CTA record it is
referring to?

Section 5
---------

It is important to add a note here that the Child DNS Operator (or some
software) must delete old DNSKEYs only after verifying that the parent
zone has updated its DS records to match the new ones.

It is also important for the Child to not directly switch CDS / CDNSKEY
RRs (once published):

* before sending them through DNSKEY RRs first, and

* before verifying that the parent has updated to the new CDS / CDNSKEY
  data

as the parent may be in the process of updating to the new DS records
when such a change happens, breaking the chain.

Section 6.1.1
-------------

> environments the registry is prohibited from talking to the
> registrant.  In most these cases the registrant has a business

"most these cases" => "most of these cases"

Section 6.1.2
-------------

> DNSSEC, these mechanisms can be unauthenticated (for example, a child
> could call his parent and request the CDS action be performed, an

"could call his parent" => "could call its parent"

What does "CDS action" mean here? It should be described or this
sentence could be rewritten.

Section 6.2
-----------

If every nameserver is to be checked for the CDS / CDNSKEY RRs, what is
the action to be taken when there is a mismatch? Which CDS is used?

Section 9
---------

> This work is for the normal case, when things go wrong there is only
> so much that automation can fix.

Please change the comma to a full-stop.

> not detected before the DS in parent is changed.  If this type of
> change takes place, the child need to contact the parent (possibly

"child need to" => "child needs to"

> While it may be tempting, this SHOULD NOT be used for initial
> enrollment of keys since there is no way to ensure that the initial
> key is the correct one.  If is used, strict rules for inclusion of

Perhaps "authentic" or "valid" are better words than "correct" in this
context.

Some overall notes
------------------

"Child operator" and "Child DNS operator" are both used. Please update
the document to use the one defined in the "Terminology" section.

Can't the equivalent of CDS / CDNSKEY be achieved by introducing
additional DNSKEY RRs (with SEP=1) in the child zone that are polled by
the Parent DNS operator? Is it really so important that the child must
have control (overriding the parent's choice) over the value of fields
used in the DS record? For example, the parent operator can use the same
algorithm, etc. as in the initially configured DS record.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 5 Jan 2014 05:25:23 +0530

> algorithm, etc. as in the initially configured DS record.

s/algorithm/digest/ here.

		Mukund

---

From: Warren Kumari <[email-masked]>
Date: Sat, 4 Jan 2014 20:52:12 -0500

> > We think that this resolves the open comments and is ready for WGLC.

Awesome, thank you for the detailed review (and even more so for the text
:-))
I have incorporated most of your comments / suggestions - a few of your
comments / questions require some more thought / discussions with
co-authors, but I wanted to respond on the ones I've incorporated.

> "CDS" is used without any prior description of it.

Doh! Thank you.
Changed it to: "The solution described in this document only allows..." to
avoid cluttering up the Into.

> Section 1.1
DONE.

> Section 2.1

Fair 'nuff.
DONE.

> May I suggest changing "keys(s)" => "DNSKEY(s)"?
You may :-)
DONE.

> represented in the parent zone's DS records."

I changed that slightly to be:
As the DS record can only be present at the parent, some other
record/method is needed to automate which DNSKEYs are picked to be
represented in the parent zone's DS records.
(added record / method). Does that work for you?

> point keys would be good to have here.

Fair 'nuff.
I'll chat with Olafur about this (and your other comments in this section)
to try draft better text. I cannot remember all the details, but AFAIR
Olafur explained the reason well in an email somewhere- will try drudge
that up...

> keys are not in the DNSKEY RRset? Such minor clues are useful when

How is:
"In another common case an enterprise may delegate parts of its name-space
to be operated by a group that is not the same as that which operates the
enterprise's DNS servers. In this case the flow of information is
frequently handled in either an ad hoc manner or via some corporate
mechanism; this can range from email to fully-automated operation. The word
enterprise above covers all organizations where the domains are not sold on
the open market and there is some relationship between the entities."

Still a little wordy, but I think better?

> Section 2.2.1

DONE.

> "Parents Provisioning system" => "Parent's Provisioning system"

DONE.

> anchor" in the abstract too.

Hmmm... We mean the DNSSEC key information. AFAIR we used the phrase 'trust
anchor' to decouple from either DNSKEY or DS.
How is: "Some parents want the child to express their DNSKEYS in the form
of DS records, while others want to receive the DNSKEY records and
calculate the DS records themselves."?

> parent zone." (i.e., not all delegation information in the parent zone.)

;-) Cute.

DONE.

> operational mistakes will happen, or worse, the update action is not
Excellent. Thanks for the text.
DONE.

> (also note the apostrophe in "parent's").

DONE and DONE.

> Where is version -04 of this document? What is this CTA record it is

Doh. The document is
http://tools.ietf.org/id/draft-kumari-ogud-dnsop-cds-04.txt -- this was
before this was adopted, I'd forgotten to update the text. Now fixed.
The CTA record was the closest to consensus I've seen DNSOP come recently
-- basically there was consensus that it was a shitty idea and I should be
beaten round the head for suggesting it :-)

> when such a change happens, breaking the chain.

Will do. Will wait to discuss with Olafur -- my brain is mush at the
moment...

> Section 6.1.1

DONE.

> Section 6.1.2

DONE.

> sentence could be rewritten.

DONE.
"As the CDS / CDNSKEY records are validated with DNSSEC, these mechanisms
can be unauthenticated (for example, a child could telephone its parent and
request that they process the new CDS or CDNSKEY record, an unauthenticated
POST could be made to a webserver (with rate-limiting), etc.)"

> Section 6.2

Will fix.

> Please change the comma to a full-stop.

DONE.

> "child need to" => "child needs to"

DONE.

> Perhaps "authentic" or "valid" are better words than "correct" in this

Hmmm... Actually I'm not sure. Perhaps "correct" is not correct. Will need
to think more.

> Some overall notes

Good catch.
DONE.

> the Parent DNS operator?

Technically yes, but see below.

> Is it really so important that the child must

This has been discussed and the consensus was that it was preferable to be
explicit that the child want an action to occur -- this allows children to
opt-in or not.
Registrars and registries want to be able to log the fact  / audit that the
child has requested this to occur -- having a separate record to signal
this allows that.
A separate record type also allows a child to pre-publish a DNSKEY record
before using it / request that the parent stops publishing it (when aging
out).

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 5 Jan 2014 10:27:22 +0530

Hi Warren

> (added record / method). Does that work for you?

This looks good.

> Olafur explained the reason well in an email somewhere- will try drudge

Nod.

> Still a little wordy, but I think better?

Yes this is much better to understand.

> calculate the DS records themselves."?

This is good. How about "supply" or "provide" instead of "express"?

> beaten round the head for suggesting it :-)

Nod. I didn't realise this had gone through many versions already. :)

> Will do. Will wait to discuss with Olafur -- my brain is mush at the

Nod. This draft is small, so perhaps it won't be too bad to include a
section listing ordered steps from how a parent fetches a new CDS or
CDNSKEY to when the DS record is published. Similarly, steps for how a
child adds new CDS and CDNSKEY records and removes the old keys can be
included.

The hazard of not implementing it correctly is that resolvers determine
the data is bogus and things fail to resolve. So it's better to provide
step-by-step instructions that implementors can keep in mind.

> POST could be made to a webserver (with rate-limiting), etc.)"

This looks good.

> > the action to be taken when there is a mismatch? Which CDS is used?

Nod.

> before using it / request that the parent stops publishing it (when aging

I follow why it was done now. So this is to clearly mark that the
CDNSKEY is for the specific purpose of pulling into the parent (as per
this draft) and other DNSKEYs are not picked up. It may be good to add
this as a comment in the introduction (why a new record type was
created).

Because the wire format of CDNSKEY matches DNSKEY exactly, why hasn't an
extra flag been introduced in the DNSKEY RDATA instead of creating
additional RRtypes? The DNSKEY Flags field is 16-bits wide and only 2
bits are currently in use. Software that is supposed to manage this on
the child DNS operator side can easily switch the key from
"marked-for-pickup-by-parent" to "normal-DNSKEY" by changing a bit.

Using the DNSKEY RRtype would mean that existing resolvers can be used
as-is to validate the new DNSKEYs when fetched by the parent DNS
operator. Existing authoritative servers can serve them on the child
operator side. Implementors have less code to maintain.

		Mukund

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 07 Jan 2014 08:42:59 +0100

Hi,

About Child's CDS / CDNSKEY publication, I still think that it is too
strong that the Child DNS Operator SHOULD/MUST delete the CDS RRset when
the Parent DS is "in-sync". This should be a MAY.

As Joe Abley pointed out, keeping the CDS/CDNSKEY published is a nice
addition for debugging/monitoring purposes.

When the Parent sees that the CDS/ CDNSKEY RRset is empty, no action
should be taken. When the Parent sees that the CDS / CDNSKEY RRset is
already "in-sync", no action should be taken.

Best regards,
  Matthijs

On 01/04/2014 10:21 PM, Warren Kumari wrote:
> On Sat, Jan 4, 2014 at 3:40 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 7 Jan 2014 23:53:36 -0500

Mukund, 

thanks for your review I will respond to the points that Warren did not 
address in his reply. 

> point keys would be good to have here.

Hum Hum, the introduction and Background sections are supposed to do provide the 
background, did we fail in conveying that message ? 

> with SEP=1 from the child zone? (How are these DNSKEYs validated?) This

This is background not protocol at this point, so I do not want to get into 
validation at this point. 

> keys are not in the DNSKEY RRset? Such minor clues are useful when

The point is Child may want DS records referring to future/past/backup DNSKEY records 
but does not want to include them in the DNSKEY RRset for some reason including size. 

> intended to be described).

There is no harm if the Child at time T publishes CDNSKEY and at time T+1 day publishes corresponding CDS 
as long as they are the same.
 If child discovers after publishing CDS that that parent wants CDNSKEY it is harmless to
switch the out CDS for CDNSKEY 

Your point that the child should not break the delegation by removing an "active" DNSKEy is a good
one and was too obvious to me, will add text to that effect. 

Strictly speaking this is "local policy" for the parental agent. 
But, assuming all the CDS/CDNSKEY records pass DNSSEC validation. 

--> In this case the parental agent should ignore the records
and hope the situation is sorted out next time it checks. 

If only some of the CDS/CDNSKEY validate then those that validate should be identical before triggering update to parent DNS. 

It is quite possible that things are out of sync due to the loose-consistency of DNS and delays in getting new versions of zones to
all secondaries. 
Not matching includes that some name servers have CDS/CDNSKEY records and some do not. 

Thinking about adding this text: 
Parental Agent is free to poll as many name servers for the child as it wants to check if they agree on the contents of the
CDS/CDNSKEY records, only if all the checked servers have identical records should the records be accepted. 

Note; 
This case is one of the reasons I want children to remove the C* records after parent performs the update, 
then there is no chance of JoJo updates by parent depending on which Nameserver is polled. 

> Perhaps "authentic" or "valid" are better words than "correct" in this

"Correct" is the appropriate word here, as it refers to a key(s) that have been presented
via some authenticated out-of-band method. 

> Some overall notes
Thanks for great helpful review, 

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 8 Jan 2014 23:40:49 -0500

On Jan 8, 2014, at 4:03 AM, Matthijs Mekking <[email-masked]> wrote:

> On 01/08/2014 05:53 AM, Olafur Gudmundsson wrote:
>> Note; 
> But the parent would still need to deal with the case that the C* is the
> same: The child may not yet have removed the record because it had not
> yet come to the conclusion that all DS records at the parent name
> servers are in sync. In this scenario, the parent shall also not take
> action (just like if there was no C* RRset).
> 
> I think looking at the inception time is a better approach to prevent
> JoJo updates.

So you want an Parental Agent to look inside the RRSIG(s) as tiebreaker ?

	Olafur

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 09 Jan 2014 10:06:03 +0100

> So you want an Parental Agent to look inside the RRSIG(s) as tiebreaker ?

Yes. And I don't see any harm in that: The Parental Agent already has to
check the packet because of the Continuity rule.

Best regards,
  Matthijs