Re: [Gen-art] Gen-ART LC review of draft-ietf-dnsop-delegation-trust-maintainance-13.txt

[Warren Kumari <[e-mail]>]

On Mon, May 19, 2014 at 10:15 PM, Brian E Carpenter
<[e-mail]> wrote:
> (sorry, retransmission with corrected address)

Yeah, I do that as well, especially with directorate reviews...

>
> I am the assigned Gen-ART reviewer for this draft.

Thank you, A: for doing the review, and B: doing it early.

Apologies for taking so long to respond - I was procrastinating, and
also wanted to check with my co-author before responding.
Unfortunately I was unable to reach him on Jabber (I seem to remember
he had some travel), and so anything stupid below is my fault, not
his.

>  For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-dnsop-delegation-trust-maintainance-13.txt
> Reviewer: Brian Carpenter
> Review Date: 2014-05-20
> IETF LC End Date: 2014-05-26
> IESG Telechat date:
>
> Summary:  Almost ready
> --------
>
> Minor issues:
> -------------
>
>> 1. Introduction
> ...
>> Any manual process is susceptible to mistakes and / or errors.
>
> Also susceptible to social engineering or malicious leaks, I think.
> There's a fairly strong security argument for getting humans out
> of the process.

Yes. But, assuming it is OK with you / the IESG, I'll not mention that
-- while true, it seemed like a distraction, and some of the customers
(registrars) are kinda sensitive about the whole social engineering
issue :-)


>
>> 3. CDS / CDNSKEY (Child DS / Child DNSKEY) Record Definitions
> ...
>> it is up to the consumer of the records to
>> translate that into the appropriate add/delete operations in the
>> provisioning systems
>
> Not clear here whether this is expected to be an automated or manual process.

On the parent side it is intended to be automated -- it *could* be
done manually, but probably will be an automated (the child side can
be either automated or manual, see below).

"... it is a "replace" operation, and it is up to the software that
consumes the records to translate that ..."
Better / clear?

>
>> If no CDS / CDNSKEY RRset is present in child,
>> this means that no change is needed.
>
> Not clear here how we ensure that update is performed exactly once. See below.

I think I've clarified that some (see below, and will post an updated
version soon (also incorporating comments from SM, and Olafur away at
moment, want to key his ACK on text).
This is "if the parent polls, and sees no CDS / CDNSKEY, it goes back
to sleep". The reason we added this clarification is:
1: Initially no domains will have CDS records, even those that do
currently have DS records.
2: Without this clarification, the parent might think "The CDS means
'Make the DS for the child look like what the child published. The
child published nothing, so, obviously, I should remove the DS'"
3: Now everyone who has a DS has none, and they come shout at us :-)

>
>> 4. Automating DS Maintenance With CDS / CDNSKEY records
>>
>> CDS / CDNSKEY resource records are intended to be "consumed" by
>> delegation trust maintainers.  The use of CDS / CDNSKEY is optional.
>
> I think that could be OPTIONAL.

DONE.

>
>> The child SHOULD publish both CDS and CDNSKEY resource records.
>
> Given the previous sentence, I think this needs to be
>
>  If the child publishes either the CDS or the CDNSKEY resource record, it
>  SHOULD publish both..

DONE.


>
>> 4.1. CDS / CDNSKEY Processing Rules
> ...
>> If there are no CDS / CDNSKEY RRset in the child, this signals that
>> no change should be made to the current DS set.  This means that,
>> once the child and parent are in sync, the Child DNS Operator MAY
>> remove all CDS and CDNSKEY resource records from the zone.
>
> Does that mean the the child MAY/SHOULD/MUST monitor what the
> parent is publishing in order to automate this process? If not, you
> are calling for a manual operation. (The text in section 5
> is repetitious, by the way, but still doesn't clarify this.)


Hmmm. We are not really expecting that children will do this very
often / ever -- it is allowed, but extra work for the child. The (IMO)
most likely way that this will happen is that a child will publish a
new zone file without the record in, either because they didn't
recognize it or because some post-processing script actually adds the
record, and the post-processing script didn't run (or something
similar).

However, it is allowed, and so we need to define it better -- this
could be either a manual process ("I don't have a tool to manage my
small number of domains, so I manually add the CDS and then, after
lunch I check and see if the parent has picked it up yet. If so, I
manually remove it") or whatever DNSSEC provisioning / management tool
is used can automatically poll and automagically remove it.

Also, your more general comment of "is this manual, or automated" --
it is designed to work well in either scenario. Increasingly we see
that folk are using toolsets that manage their DNSSEC key stuff (BINDs
auto-dnssec stuff, DNSSEC-Tools, OpenDNSSEC, etc) and we expect these
to take over automagically doing this. If, however, you like doing
things manually, it works well for you as well.

I've tried to clarify this with:
"The CDS / CDNSKEY resource records are published in the child zone
and gives the child control of what is published for it in the
parental zone. The child can publish these manually, or they can be
automatically maintained by DNS provisioning tools."

How's that?


>> If any these conditions fail the CDS / CDNSKEY resource record MUST
>> be ignored.
>
> Silently? Should this be logged?

Good point. Sometimes I think that logging things is indistinguishable
from silently failing, but... :-)

" If any these conditions fail the CDS / CDNSKEY resource record MUST
be ignored, and an error SHOULD be logged."

 Any DOS potential here? Should use of
> these RRs be rate-limited in both child and parent to avoid any DOS risk?


I really don't see this as being a DoS risk -- the 2 parties here
could just as easily (intentionally or unintentionally) DoS themselves
with any other set of records.
We are only really specifying the "Parent polls" method of operation
-- and the parent is the one who would be doing the majority of the
work (the child just answers a single DNS query). We are expecting
that the polling will take place on the order of a few hours, not
seconds (the parent has no real incentive to do this faster, and even
if they do, it's a single DNS lookup on the child) IF the child polls
the parent, they might poll more often -- but, children already do
this. For example, children poll their parents to monitor for changes
/ updates / incorrect NS, etc.

>> 6. Parent Side CDS / CDNSKEY Consumption
>
> I don't think you specify what the parent should do if it receives
> both a CDS and a CDNSKEY and they are inconsistent (in violation
> of section 4). Yes, it's a corner case but Murphy's law always applies.

Oh dear. You appear to have walked right into a controversy...

We have "The parent MUST choose to use either CDNSKEY or CDS resource
records as their default updating mechanism. The parent MAY only
accept either CDNSKEY or CDS, but it MAY also accept both, so it can
use the other in the absence of the default updating mechanism, but it
MUST NOT expect there to be both."

The "MUST NOT expect there to be both" is intended to avoid this
issue. The parent is not supposed to compare the two, and so it should
never know if there is an inconsistency (and, therefore, it doesn't
need to do anything).


In earlier versions of the document we had:
" If the child publishes both, the two RRsets MUST match in content.
The parent should use whichever one they choose, but MUST NOT query
for both and perform consistency checks between the CDS and CDNSKEY
records."

and before that:
"If the child knows what the parent prefers, they can publish the
   parent's preferred record type.  If the child does not know (or
   simply chooses to), they can publish both CDS and CDNSKEY.  If the
   child publishes both, they SHOULD have matching CDS records for each
   CDNSKEY record.  The parent should use whichever one they choose, but
   SHOULD NOT query for both and perform consistency checks between the
   CDS and CDNSKEY records.

[Editor note: It is not an error for a child to have published CDS
   records and not have CDNSKEYs that hash to those records, nor for
   there to be CDNSKEY records without matching DS records.  This is
   because a child might have been publishing CDS records and then the
   parent's policy changes to require CDNSKEY records.  The child might
   forget to remove the CDS, etc.  This avoids all sorts of error
   conditions / complexity, etc.]"
and:
" A child MAY publish both CDS and CDNSKEY. If a child chooses to
   publish both, it SHOULD attempt to maintain consistency (a matching
   CDS for each CDNSKEY)"

and before that some text scarred through out the document, but including:
"The parent MUST choose to accept either CDS or CDNSKEY records, and
   MUST NOT expect there to be both.  A parent SHOULD NOT perform a
   consistency check between CDS and CDNSKEY (other than for
   informational / debugging use).
"

There was a long, and protracted discussion that arrived at the
current text. I'll let Olafur chime in here as well...


>
>> 9. Security Considerations
> ...
>> 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
>> keys such as hold down times, challenge data inclusion or similar,
>> ought to be used, along with some kind of challenge mechanism.
>
> Shouldn't that "ought to" be MUST? Weak protection against a bogus
> initial key really seems like a "Crypto Won't Save You Either" poster
> child.

LGTM.
I seem to remember some reason we arrived at this text, but I've been
unable to find it again. I'll make the change, unless Olafur can
remember?

>
> Nits:
> -----
>
> (from the shepherd's write-up)
> "The document references the document draft-ietf-dnsop-dnssec-key-timing, which had
> been approved for publication but never followed through on, and is shown to be expired."
>
> This is an informational reference and could probably be deleted without harm.

DONE!

>
> "Additionally, the document references RFC2119 key word "NOT RECOMMENDED" without referencing it. "
>
> That is a well known bug in RFC 2119 itself. The citation can be fixed as per
> http://www.rfc-editor.org/errata_search.php?eid=499

Oooh! Thanks.

Please let me know if the clarifications / explanations address your
concerns. Also, I was unable to

W