At 05:21 12-05-2014, The IESG wrote:
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
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
