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

Daniel Migault <mglt.ietf@gmail.com> Wed, 06 May 2020 21:58 UTC

Return-Path: <mglt.ietf@gmail.com>
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 ADA063A0AA3; Wed, 6 May 2020 14:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3wuaiNn3pZOt; Wed, 6 May 2020 14:58:08 -0700 (PDT)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C773A0B92; Wed, 6 May 2020 14:58:08 -0700 (PDT)
Received: by mail-ua1-x935.google.com with SMTP id z16so1108825uae.11; Wed, 06 May 2020 14:58:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FOuG06Ty7A/DrqSNyC2YdRkLIXJI3dytEf+XxXcZEkU=; b=q/fvVx5AyNcHv5db/HnSDMTEiofBbU2Bg4P7J4Ufj9va4JcMc+APSU7q+ks6bjBUJE VNd2ujtJS3BOIx5g0jOaZ8iLfDJreOF1y7bFNtRH9SkcqJU0cKxCYSsEVbdeRyAuiJdy IUrKKBSy6hShLwIPloZkN04u7Y+W2oFlRiXO7OwcTDNVcbz5jYYPWft+xNEju+eI0T5a +BruiD8nS405jkq6fRZcexQHnX2N+u0dySEpAkdYi/eOAhmQ2zDo9XhKJC1e3QGEYz1k MpSxPbV9E0w4tv/reGbNP9UIb5KuB9L5CsfAXKD2vzjtitKrZ/n0lMu6ThAB8VUdb4P9 6FFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FOuG06Ty7A/DrqSNyC2YdRkLIXJI3dytEf+XxXcZEkU=; b=OSVGliscl9bsjO1c0hSC85BOHcwEEL4wMMPfl337yMmmNQ4SeGNCSovAuUURRn5txa N2ZEOBhXNlmiat4Hzu4EiiD635ew3TFuZonF/zBqI9P6OheyoRLhGPLWn1oBnXjpQmR5 BJeqIWHl3eU0cXKwDRLcHKTJyR4nT8qAI6mUA38FU+13x5LPpAdrtODImdciafc4ybh8 gAFqVgnUUEY6deS8Zu9gfCQwbmJS5mM53txQn2OgU7TFaN94VmKs7b6pjawJ2Qg8Gw7t f3nQWKKgM+YObFrl57AULNEQclEWvnXm8jxACIKACqLM1FfCKWsFfdbzeF25pUQr/h1f bmEA==
X-Gm-Message-State: AGi0PubBWvS7ejicYcKyFoqRf/eQL0fbTlWoQ+EgmkXj7LKYdB8UVzq5 tOWKB/6umjZBn2WzgsAROOnRBljh77/9o7G+cDs=
X-Google-Smtp-Source: APiQypIh5gcCBB8KEXBJpmyLpCvtAmyVDF/EtvAZseWekABj36ersdbEsoD6jZc1ehQIgCURHXAjUZQUdfvCVc6uetA=
X-Received: by 2002:a9f:222c:: with SMTP id 41mr9081962uad.88.1588802287427; Wed, 06 May 2020 14:58:07 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+HTU92FYYFvogsur9jSZ+qj03PWPVNbiWSe4g_zCn=5wg@mail.gmail.com> <20200506084836.GA14813@nic.fr> <c01c4537ad934cd0b4be5f1e49180e9c@cira.ca>
In-Reply-To: <c01c4537ad934cd0b4be5f1e49180e9c@cira.ca>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 6 May 2020 17:57:56 -0400
Message-ID: <CADZyTkm8+r_SOhx+6Ec4nwZTD3ri-mOh4dtcaL-87jbENAe+uQ@mail.gmail.com>
To: Jacques Latour <Jacques.Latour@cira.ca>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f5e81705a501dbd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3GU4vg4krAn9sJyyA1T6IBflpyA>
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 21:58:11 -0000

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>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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson