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

Warren Kumari <warren@kumari.net> Sun, 05 January 2014 01:52 UTC

Return-Path: <warren@kumari.net>
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 D96FA1AE0CF for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2014 17:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Level:
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Iv2q0Ouwn2ym for <dnsop@ietfa.amsl.com>; Sat, 4 Jan 2014 17:52:21 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAB81AE09E for <dnsop@ietf.org>; Sat, 4 Jan 2014 17:52:20 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so14513906wes.40 for <dnsop@ietf.org>; Sat, 04 Jan 2014 17:52:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F9XqkMGABuTigfB/SrHtlRTkd6RosIoEY7Kj8QF8O4E=; b=mO2RLSC0U09yOI3QiOTiA8Ws15KWYMbj8lATQRCQ/whZ85eYv5IKDrMgAmOupFUIQx wIIRFfHWaKX/SajEHCA8TXwYddaKYqEq5WmtXREauuiW2lt+eLiNePoXnoNeH2kF1rNz ZWM7icXSkbPseepZ2oSmrm/PHKWWjiQ0aCC1NJa8kMgqEzqtGuIA28X7BOLui3WV7OKM dGSBx8Ys18SMDhUVkxxdYaC0VMnp4U50tcZnz9lCk+I9Lxm1Kn3jFOrwvqYu8NVCNorl Zjgln195cOk1OPUhqP/OYTB6cuTZwUn6suVK2xsrxIY0NREDUFWUn762jdXe8seQQqsv 9STg==
X-Gm-Message-State: ALoCoQlKIRx3PVHlRoviya5y+XXwOw5sPqIa5bhgEemy5n6yCWzJkYc9oStjzVA6cMOZmG1f3FHx
MIME-Version: 1.0
X-Received: by 10.194.6.161 with SMTP id c1mr88049wja.89.1388886732634; Sat, 04 Jan 2014 17:52:12 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Sat, 4 Jan 2014 17:52:12 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: <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> <20140104235045.GA24696@totoro.home.mukund.org>
Date: Sat, 4 Jan 2014 20:52:12 -0500
Message-ID: <CAHw9_iJ3z58PpoLi+1Cb6mgAo-8mNv9E_m-t-CwOZDVJ1q=vCA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Mukund Sivaraman <muks@isc.org>
Content-Type: multipart/alternative; boundary=047d7b4175a355116304ef2f64da
Cc: dnsop <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: Sun, 05 Jan 2014 01:52:26 -0000

On Sat, Jan 4, 2014 at 6:50 PM, Mukund Sivaraman <muks@isc.org> 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:
>

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.




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

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


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


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

Fair 'nuff.
DONE.


>
> > 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)"?
>
>
You may :-)
DONE.



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



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


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

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

DONE.


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

DONE.


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

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

;-) Cute.

DONE.


>
> > 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."
>
>
Excellent. Thanks for the text.
DONE.


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

DONE and DONE.


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



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

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

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

DONE.


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

DONE.


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


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

Will fix.


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

DONE.

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

DONE.

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

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



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

Good catch.
DONE.


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


>
>                 Mukund