Last Call Review of draft-ietf-dnsop-dnssec-validator-requirements-04
review-ietf-dnsop-dnssec-validator-requirements-04-secdir-lc-kaufman-2023-05-11-00

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<http://aka.ms/weboutlook>