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

[Olafur Gudmundsson <[e-mail]>]

Mukund, 

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

On Jan 4, 2014, at 6:50 PM, Mukund Sivaraman <[e-mail]> wrote:

> Hi Warren
> 
> On Sat, Jan 04, 2014 at 04:21:03PM -0500, Warren Kumari wrote:
>> We think that this resolves the open comments and is ready for WGLC.
> 
> Here are some comments:
> 
> 
>> 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.

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


> 
>> 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.

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

> 
>> 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.
> 

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. 



> 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.
> 

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. 

> 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?

> 

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. 

> 
>> 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.
> 

"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
> ------------------
> 
> "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
Thanks for great helpful review, 

	Olafur