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

[Stephane Bortzmeyer <[e-mail]>]

On Mon, May 04, 2020 at 03:08:20PM -0400,
 Tim Wicinski <[e-mail]> 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.

> 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 :-{

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"?

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

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?

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