Re: [secdir] Secdir review of draft-ietf-dnsop-dnssec-validator-requirements-04

[Daniel Migault <[e-mail]>]

Hi, 

Thanks for your review. The current version is a significant re-write of the version you reviewed. In the light of the following comment: 

"""
Reword. This document is not about avoiding responsibility or liability; it's about doing the right thing.
"""
You can find the current version here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/

We removed many discussions, considerations that are not intended to a DRO as well as those not actionable by a DRO. I believe that was a major concerns of our document and the document is now much concise, clearer and addressing the sues you raised.

You can find a more detailed response on the high level comments below.

Yours, 
Daniel 
________________________________________
From: Charlie Kaufman <[e-mail]>
Sent: Saturday, May 6, 2023 7:35 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: Secdir review of draft-ietf-dnsop-dnssec-validator-requirements-04

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.

<mglt>
We did proceed to a major rewrite and believe we addressed that issue.
</mglt>

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.

<mglt>
I agree that the previous version had considerations that were outside the scope of the DRO. In some case, the recommendation was more targeting the implementers I agree. This includes the management of the TTL for example which has been removed. 

Our primary goal for automation was to insist on limiting manual intervention by the DRO and them being prepared wit the right tooling to perform some specific operations. In some cases, such as TA Updates, DNSOP have defined mechanisms. We recommend the DRO to enable these mechanisms.
  
In other cases, it is part of the DRO to set the right tooling (scripts) to fullfill some tasks. For example to retrieve the up-to-date TAs. In that case, our recommendation is mostly for the DRO to leverage on existing piece of software.  In some case, that software is embedded in the resolver it is using.

I believe the current version clarifies the need to automate procedure and provides more guidance on the tooling aspect versus the mechanisms that   are implemented by the resolver implementer. Writing these lines, I realise that any time we mention a DNSOP defined mechanism I always had in mind this will be made available to the DRO, and the DRO only has to enable it.  If that is unclear I am happy to clarify that.
</mglt>

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.

<mglt>
I think in the old version as well as in the new version we have emphasise on the DRO to be able to communicate with the other actors involved in the DNS. So far we are recommending to provide extended errors to the client, the ability for authoritative server, and encourage reporting. We received some comments that it was unclear whether extended error are used with client or something else. I guess the current version is clearer.

The recommendation you suggest that is informing a DNS client whether DNSSEC has been validated or not is interesting, but as far as I know, it does not exist and sounds like a new work to be done. I am unsure such work would be adopted by dnsop as setting cd is probably how this could be implemented. There might be some space where such indication mght make sense when DNSSEC and TLS are combined. Typically, without TLS, unless DNSSEC validation is performed by the client, the client cannot trust the response (even when received from a trusted resolver that has performed the DNSSEC validation). With TLS it could make sense to indicate DNSSEC were present and implicitly signature validation succeeded.

The extended errors are expected to guive more  information to the DNS client but we do not designed a mechanism for teh client to accept the unsigned or RRsets with a validation failure. This is likey to involve some sort of GUI and falls in the  category of new work. 

Such new work are not mentioned as these are expected to be implemented by the resolver vendors and not the DRO, but it also carry the message that DNSSEC deployment is complex.... and actually one purpose of this document is to show that DNSSEC can be deployed quite easily. 
</mglt>

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.

<mglt>
We do refer to negative trust anchor recommendations that have its own document. 
</mglt>

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.

<mglt>
Actually we are trying to mention that DRO can be done properly with some minimal effort. We also want to highlight that willing to have some specific settings - such as specif rules to handle the cache, specific trust model -- can become very easily complex, and maybe should be avoided.
The version you reviewed was probably providing too much discussions on corner cases, risks evaluation giving an impression of an unnecessary complexity. I believe the current document addresses this concern.
</mglt>

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

<mglt>
Well... this is clearly something the DRO would be responsible to do. I agree that also applies to non DNSSEC resolver.... but DNSSEC likely reveals such issue. As far as I can tell more generic spec are likely to be more generic. We did not change this section. We also added a section on secure transport, in that case, we did not repeat the TLS BCP bu simply refer to the specific document. 
</mglt>


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>