Subject: [DNSOP] Last Call: <draft-ietf-dnsop-delegation-trust-maintainance-13.txt> (Automating DNSSEC Delegation Trust Maintenance) to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 12 May 2014 05:21:59 -0700

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Automating DNSSEC Delegation Trust Maintenance'
  <draft-ietf-dnsop-delegation-trust-maintainance-13.txt> as
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-05-26. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes a method to allow DNS operators to more
   easily update DNSSEC Key Signing Keys using the DNS as communication
   channel.  The technique described is aimed at delegations in which it
   is currently hard to move information from the child to parent.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 May 2014 02:07:54 -0700

>final comments on this action. Please send substantive comments to the

As the intended status of this document is Informational I don't have 
a strong opinion about the following comments.

 From the Abstract:

   "This document describes a method to allow DNS operators to more"

In Section 1:

   "This document outlines a technique in which the parent periodically
    (or upon request) polls its signed children and automatically"

   "This document describes a method for automating maintenance of the
    delegation trust information, and proposes a polled / periodic
    trigger for simplicity."

There is also a mention of "technique" in the Abstract.  The is a 
lengthy discussion of what the document, technique and method is 
about in the first six pages.  Which section(s) describe the method 
or technique?

It is only when I read Section 3 that I found out that the document 
specifies two new DNS resource records.  The two new DNS RRs are uses 
interchangeably in that section.  It would be better to have a clear 
definition of each resource record.

Section 3.1 provides a pointer to RFC 4034 for the reader to see the 
wire and presentation format of the CDS RR.  There is then a mention 
of how IANA has allocated the code and some text about the CDS RR 
using the same registries as DS.  It would be better to include the 
wire format in the document as that might be the information a reader 
would look for.

 From Section 4:

   'The child SHOULD publish both CDS and CDNSKEY resource records.  If
    the child knows which the parent consumes, it MAY choose to only
    publish that record type (for example, some children wish the parent
    to publish a DS, but they wish to keep the DNSKEY "hidden" until
    needed).  If the child publishes both, the two RRsets MUST match in
    content.'

I have seen an approach similar to the above in another (non-DNS) 
RFC.  In my opinion, a "must match in content" open the door to 
inconsistent content as mistakes do happen.  The recommendation to 
publish both RRs and to publish only one RR if the RR that the parent 
will use is known doesn't encourage standardization.

 From Section 6:

   "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 first sentence states that the parent must choice either RR.  The 
second sentence states that the parent may accept either RR but it 
must not expect there to be both.  It looks like the DNSOP WG could 
not agree on a choice and decided to keep the proponents of each RR happy.

Section 6.1 explains that the "Pushing" is simply a button in a web 
panel and "polling" is about someone operating a tool.  I gather that 
this is all a matter of relationships and contracts.

The following stence in Section 6.2 is odd:

   "The Parental Agent MAY take extra security measures."

And this one is an odd usage of a RFC 2119 key word:

   "However the precise out-of-band measures that a parent zone SHOULD
    take are outside the scope of this document."

A diligent Area Director would file a DISCUSS if he or she notices 
that.  Making extra security measures optional makes it sound like 
the DNSOP WG has not given due consideration to security measures.

Section 8 discusses about privacy considerations.  The only sentence 
states that all the information handled by this protocol is 
public.  There isn't any description of a protocol in the document.

In Section 9:

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

What does "this" refer to in the above?

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

The above sentence is difficult to parse (re. if is used).

   "The CDS RR type should allow for enhanced security by simplifying
    process."

Which process is being referred to in the above?

   "As this introduces a new mechanism to update information in the
    parent it MUST be clear who is fetching the records and creating the
    appropriate records in the parent zone."

Is the usage of "must" in the above for contractual purposes?

   "If there is a failure in applying changes in the child zone to all
    DNS servers listed in either parent or child NS set it is possible
    that the Parental agent may get confused, either because it gets
    different answers on different checks or CDS RR validation fails."

Does that mean that the entity will be confused?  Shouldn't the issue 
be about inconsistent information?

   "By automating the maintenance of the DNSSEC key information (and
    removing humans from the process), we expect to decrease the number
    of DNSSEC related outages, which should increase DNSSEC deployment."

What does the above have to do with Security Considerations?  How 
many of the DNSSEC-related outages are due to human error?

Regards,
S. Moonesamy