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

Mukund Sivaraman <muks@isc.org> Sat, 04 January 2014 23:51 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B01AE0C3 for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2014 15:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XxCZt3Ru6QP for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2014 15:51:03 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id A4EC71AE0C2 for <dnsop@ietf.org>; Sat, 4 Jan 2014 15:51:02 -0800 (PST)
Received: from totoro.home.mukund.org (unknown [115.118.150.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 58FAFE600EF; Sat, 4 Jan 2014 23:50:50 +0000 (GMT)
Date: Sun, 05 Jan 2014 05:20:45 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20140104235045.GA24696@totoro.home.mukund.org>
References: <20140104204035.7446.24984.idtracker@ietfa.amsl.com> <CAHw9_iKbHbt7+j=C2ub=vRR+0rNgU+3P=WjnpV4gnY=y=q4xOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
In-Reply-To: <CAHw9_iKbHbt7+j=C2ub=vRR+0rNgU+3P=WjnpV4gnY=y=q4xOQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jan 2014 23:51:05 -0000

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:

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