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

[Mukund Sivaraman <[e-mail]>]

Hi Warren

On Sat, Jan 04, 2014 at 08:52:12PM -0500, Warren Kumari wrote:
> > > 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."
> >
> 
> 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?

This looks good.

> > A sentence explaining why a method is needed to automate locating entry
> > 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...

Nod.

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

Yes this is much better to understand.

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

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

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

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

> > 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.
> >
> 
> Will do. Will wait to discuss with Olafur -- my brain is mush at the
> moment...

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.

> > What does "CDS action" mean here? It should be described or this
> > 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.)"

This looks good.

> > 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?
> >
> 
> Will fix.

Nod.

> > 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?
> 
> 
> Technically yes, but see below.
> 
> 
> > 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.
> >
> 
> 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).

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