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

Hi Jacques,

Thanks you for the feedbacks. As suggested by Stephane, the document needs
to emphasize on the communication between the client and the resolver. I
open the following issue and will address this in the next version.
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/2

Yours,
Daniel

On Wed, May 6, 2020 at 2:16 PM Jacques Latour <Jacques.Latour@cira.ca>
wrote:

> I support the adoption of this document as well, perhaps a bit long but as
> Stéphane stated with draft-ietf-dnsop-extended-error, it would nice to have
> a good story on understanding why resolvers return SERVFAIL.
>
> >-----Original Message-----
> >From: DNSOP <dnsop-bounces@ietf.org> On Behalf Of Stephane Bortzmeyer
> >Sent: May 6, 2020 4:49 AM
> >To: Tim Wicinski <tjw.ietf@gmail.com>
> >Cc: dnsop <dnsop@ietf.org>; dnsop-chairs <dnsop-chairs@ietf.org>
> >Subject: [EXT] Re: [DNSOP] Call for Adoption:
> draft-mglt-dnsop-dnssec-validator-requirements
> >
> >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.
> >
> >> 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.")
> >
> >
> >_______________________________________________
> >DNSOP mailing list
> >DNSOP@ietf.org
> >https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
Daniel Migault
Ericsson