Reviewer: Charlie Kaufman Review result: Has Serious Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This I-D has problems. First, there are an excessively large number of typos and awkwardly worded sentences with sometimes make it's interpretation difficult. I've listed the first few I found below but was eventually exhausted. Perhaps more importantly, the recommendations talk about what a DNSSEC Resolver Operator should do, but have little guidance on how to do it. Mostly, this I-D illuminates problems with the existing DNSSEC deployment which makes if difficult for operators know what to do in all cases. It recommends automation in many cases, but that's really a recommendation to the implementers of DNSSEC resolvers rather than the operators. The fundamental problem with DNSSEC Resolvers is that there is no way for them to encode information about failures in the responses they send to clients that would allow the clients to decide how to handle them. DNSSEC recognizes the existence of unsigned records, and resolvers can return a single bit of status information to the effect that certain information was not signed. But if data has invalid signatures, the prescribed action of a DNSSEC resolver is to discard the information (even if they are invalid for as minor a reason as that the signature has recently expired because the zone signer failed to deploy updated signatures on a timely basis). Some clients respond to this problem by switching to a resolver that does not enforce DNSSEC, which is probably not optimal. A more correct response is probably to ask the user whether to make an exception in each (unique) case, but that is not easily available as an option. DNSSEC resolvers can be configured to ignore errors is certain parts of the name tree when it is known they are incorrectly configured, but there also there is little practical guidance as to when such an action is appropriate. At best, this document explains to DNSSEC Resolver Operators why their job is hard and the stakes involved in getting it wrong. With luck, it would also inspire someone to address some of the challenges in the administration of DNSSEC. Section 13 (Transport Recommendations) has recommendations that seem sound but I'm not sure they are possible. It would seem they would apply to any DNS resolver (though because DNSSEC involves large records, DNSSEC aware resolvers might be more affected). MTU values vary across different parts of the Internet, and I'm not aware of any general purpose solution to the problem. It might be better to refer to some other spec on based practices trying to run over UDP (assuming there is one). Detailed feedback: From the Abstract: "DNSSEC Resolver Operators (DRO) as well as operational recommendations that DNSSEC validators operators" What's the difference between a DNSSEC Resolver Operator and a DNSSEC validator operator? I believe these are the same people. "in order to implement sufficient trust that makes DNSSEC validation output accurate." Awkward wording. Not sure what you are trying to say. "include," -> "include" From Introduction: "The purpose of a DNSSEC Resolver Operator (DRO) is to provide DNSSEC validation in to their users." Reword. The purpose of a DNSSEC Resolver is to transparently perform DNSSEC validation for its clients. A DNSSEC Resolver Operator (DRO) is a person, whose purpose is best discussed with philosophers. :-) "two part:" -> "two parts:" "owner of the private being the" -> "owner of the private key being the" "As such differ the confidence into the Trust to designate which DNSKEY RR is legitimate." Reword. Not sure what you were trying to say. "be associated their respective" -> "be associated with their respective" "As TAs need to be managed over time, the trust also concerns the management procedure of the TA. This is the main concern of this document." This is ambiguous. It could refer to the procedures the operator of the TA follows in signing zones, but I believe what you're referring to here is the DRO's task of managing the set of TAs that the DR should trust. "appropriated libraries" -> "appropriate libraries" From Section 5: "A DRO needs to be able to enable DNSSEC validation with sufficient confidence they will not be held responsible in case their resolver does not validate the DNSSEC response." Reword. This document is not about avoiding responsibility or liability; it's about doing the right thing. "A DRO MUST provide a mean to..." -> "A DRO MUST provide a means to..." "Note that time synchronization is a sensible operation." You probably mean to say a "security sensitive" operation. From Section 7.2.2: "Avoiding the configuration file to be updated prevents old configuration file to survive to writing error on read-only file systems." Reword. Awkward. From Section 11: "One inconvenient to such strategy i sthat it does not let one DRO to take advantage of more recent cryptographic." Reword. Awkward.       --Charlie Sent from Outlook