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

Jacques Latour <Jacques.Latour@cira.ca> Wed, 06 May 2020 18:15 UTC

Return-Path: <Jacques.Latour@cira.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4B3A09EF; Wed, 6 May 2020 11:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrvFcMooIiDR; Wed, 6 May 2020 11:15:28 -0700 (PDT)
Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB893A09E0; Wed, 6 May 2020 11:15:27 -0700 (PDT)
X-Virus-Scanned: by SpamTitan at cira.ca
Authentication-Results: mx2.cira.ca; none
Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 6 May 2020 14:15:22 -0400
Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::c90:b1ae:52f6:5fca%14]) with mapi id 15.01.1531.010; Wed, 6 May 2020 14:15:22 -0400
From: Jacques Latour <Jacques.Latour@cira.ca>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Tim Wicinski <tjw.ietf@gmail.com>
CC: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Thread-Topic: [EXT] Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
Thread-Index: AQHWI4Mt4hKYxGgDuEmEhGolTTycBaibW+zw
Date: Wed, 6 May 2020 18:15:22 +0000
Message-ID: <c01c4537ad934cd0b4be5f1e49180e9c@cira.ca>
References: <CADyWQ+HTU92FYYFvogsur9jSZ+qj03PWPVNbiWSe4g_zCn=5wg@mail.gmail.com> <20200506084836.GA14813@nic.fr>
In-Reply-To: <20200506084836.GA14813@nic.fr>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.36.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sjuJUTqUIQXQSb6plmj1pwqBdx8>
Subject: Re: [DNSOP] [EXT] Re: Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 18:15:32 -0000

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>rg>; 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