Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

Hi Stephane,

Thanks you for the comments. Please see inline my responses.

Yours,
Daniel

On Wed, May 6, 2020 at 4:49 AM Stephane Bortzmeyer <bortzmeyer@nic.fr>
wrote:

> On Mon, May 04, 2020 at 03:08:20PM -0400,
>  Tim Wicinski <tjw.ietf@gmail.com> wrote
>  a message of 64 lines which said:
>
> > This starts a Call for Adoption for
> > draft-mglt-dnsop-dnssec-validator-requirements
>
> I think it is important to have such a document, because DNSSEC
> failures may seriously endanger the deployment of DNSSEC (which is
> already too low). The current draft seems a good starting point and I
> support its adoption.
>
> I'm willing to review. Let's start immediately with -09:
>
> draft-ietf-dnsop-extended-error (recently approved by the IESG) should
> be mentioned, since one of the biggest operational problem with DNSSEC
> is the difficulty to understand why a resolver returns a SERVFAIL to
> you.
>
>  This is a good catch and the DNS client side is yet missing in the draft.
Activation of EDE should be recommended. This provides the DNS client  has
a better understanding of the resolution, increases trust in the resolver.

I have created an issue here and will come with additional text.
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2

> More often, to date, failed validation is due to operator error and
> > not an attempt to forge data.
>
> It can be a bug in software, too. Specially with complicated things
> like NSEC3+optout+ENT+dynupdate :-{
>

This is correct. I cannot say this case the "bug" is entirely clear to me,
but at a high level the problem was due to a difference of interpretation
between a signer and authoritative server. This resulted in data the
resolver could not result in a proper validation. Even when fixed on
the authoritative part, some resolver were not handling this properly. I
believe that the experience associated to that bug could impact the
document as follows:
1) the draft should mention that validation failure can also be due to
software bugs.
2) we should have a recommendation for running different implementations
and provide the ability to switch to one in case a bug is detected.
3) What is unclear to me is how EDE could have helped in this case.

I opened the following issue:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/3

> The draft apparently do not mention advices on expiration slack (such
> as val-sig-skew-min and val-sig-skew-max in Unbound). Is there a
> consensus on (I quote Unbound documentation) "The signature inception
> and expiration dates are allowed to be off by 10% of the signature
> lifetime"?
>
>
Correct. This is not considered in the current document. I am happy to
consider the consensus. The following issue has been opened:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/4

> > However, a DNSSEC validator is not able to determine other than by
> > trying whether a signature scheme is supported by the authoritative
> > server.
>
> This one is unclear. First, the signer is not always an authoritative
> server, signature can be done offline. Second, querying the DNSKEY is
> enough, no? (Or querying the signatures, but I assume a zone won't
> publish a DNSKEY without being able to sign with this algorithm.)
>
>
Correct. In this section I wanted to emphasize on providing a validator
some means to ensure that it can safely deprecate an algorithm. While a
resolver that supports a signature scheme can apply that signature to all
received signed RRset. On the authoritative side, each zone needs to be
requested. The problem associated to request this is mostly the knowledge
of the zone.

I think the section should:
1) clarify the text and mentioning how the signature schemes are discovered.
2) It is unclear if we should keep track of the requested domain, in order
to be able to request the DNSKEYs
3) emphasize on a communication of supported algorithms between
authoritative servers and resolvers.

I have opened the following issue:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/5

Section 12 "Invalid Reporting Recommendations" is questionable. Since
> most DNSSEC validation errors are not attacks, reporting these errors
> may overload the DRO with problems she can do nothing
> about. Monitoring is a good idea but monitoring what? "Important" (for
> the DRO) domains?
>
>
I agree that we could be a little be more specific. At minimum I envisioned
logging the domains with the number of failures and reporting those with a
threshold.
I opened the following issue:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/6

> Also, the draft has many, it seems, grammar / language
> problems. ("This introduces a potentially huge vector for
> configuration errors, but due to human intervention as well as
> potential misunderstanding of ongoing operations.")
>
> This erro has been raised by Bob and already corrected in the version on
the repository:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd

The correct text is:
This introduces a potentially huge vector for configuration errors, due to
human intervention as well as potential misunderstanding of ongoing
operations.

Others grammar and language issues have also been corrected.

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
Daniel Migault
Ericsson