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

[Olafur Gudmundsson <[e-mail]>]

On May 30, 2014, at 5:11 PM, Warren Kumari <[e-mail]> wrote:

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

Yep

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

The child can check and see if the parent is publishing is the same as it requested,
If and Only If that is true then the child can remove the records. 
Some tool vendors have told us that they will never do removal, but others plan on 
performing it. 
The child MUST monitor parent in order to perform a key rollover, as it should not
perform the rollover operations until it is safe based on the information that the parent is publishing in
the DS set. 

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

We make no assumptions that the child is automated only that we have created a protocol 
that can be automated. 

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

There is at least one case where CDS/CDNSKEY can be used for initial keying, 
i.e. child is required to bring up its DNS operation before the parent adds the delegation into the DNS 
in this case the parent can “trust the CDS/CDNSKEY” record as this is INITAL operation and no risk of 
hijacking. 

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

Brian thanks for great review. 
> 
> Please let me know if the clarifications / explanations address your
> concerns. Also, I was unable to
> 
> W

	Olafur