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

Bob Harold <rharolde@umich.edu> Thu, 07 May 2020 13:04 UTC

Return-Path: <rharolde@umich.edu>
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 18CB13A07AD for <dnsop@ietfa.amsl.com>; Thu, 7 May 2020 06:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 yrPlUx61IATv for <dnsop@ietfa.amsl.com>; Thu, 7 May 2020 06:04:53 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 11C873A07CB for <dnsop@ietf.org>; Thu, 7 May 2020 06:04:44 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id j3so6193506ljg.8 for <dnsop@ietf.org>; Thu, 07 May 2020 06:04:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w5cfHe58ZjPZyJ7AGeRx3mqhRl4pEkanDvouGsIWe/I=; b=BPgaK/hmWjYIdj3A8iXlAjUj0d/MaqMN5Ku4+mjRwY12DEYNpfSLUfEWSTXsrclhfq dvjUrbl7wyZr3aJnI3casbQnjKKuH0azE5qpaXQQjbKmUwX9pLwG2LXGW+eQXkGlv2vM aGO2MX7x0wWBfAIGq5RBQdjkiyNjhWv2PFYPPScu/GLd6c+4zr6KmyTQX5S90TvUHLAr brXhO5D+WUn4OLFDSlepILMqiRi2Bvvcr8pbqaoCIBE3pKna7UryrAI3Wwq2EcGUhxLO bfhP/x+tKczQOXMmQ/6qTahACV5CN6rPacb8V/eSM7Dwfh85ct4ZvaCxDSqxz5B+qSOD 8i2g==
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=w5cfHe58ZjPZyJ7AGeRx3mqhRl4pEkanDvouGsIWe/I=; b=qp4dMKGIRqRha0F/u/Xlr0XmFjdCm2G4HDZsXmNnUAhNrylYG/vJqvhttLR2+LJ99m soQmZsCrzQUcy68oPzuFL7xawSQGagNznZdrWTPT7gqsKXuTeKDmY6FARNeAKlgN5fnb yuJJr/W0BURcgXHHGVht6wHcE/XzdJgPM8icLaN4myaORpQKPY1WbJ0Rq9pyucTATqDB HDlTNtd1ntTqD39u5A6iHC8+uoB2JRLZBLtXsyaVfPhXWptdUaO1dZ6iWHuX+6/Fz3K9 XJvxoo0QdHkC+oFetnNyKKTqATUEseBKwOjh/rxZsweR+qfyBQ2+8wd+wMd6GzZ9iw8t zjDg==
X-Gm-Message-State: AGi0PuaU5YBTLmWWa2Jg+noTNpsO9hLssifmet9OMA96KsLlpqtb+DRn CfSKPTvqzedV/0PPlVc7Ib+UmWkVBwX8B4n9BewsPcwT
X-Google-Smtp-Source: APiQypL+KA/hS3iZIg6mZHCrhybJRa5pmVl9AsI379gFJzMuQNMeFfNLMlwZc00XFdEnegb0D/NWfIYt1T4AZbPQo48=
X-Received: by 2002:a2e:8512:: with SMTP id j18mr8478320lji.201.1588856681947; Thu, 07 May 2020 06:04:41 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+HTU92FYYFvogsur9jSZ+qj03PWPVNbiWSe4g_zCn=5wg@mail.gmail.com> <20200506084836.GA14813@nic.fr> <CAHPuVdULY19T3KD1u5xng_gSA54fY1wAB4xKV+PimAZyhZnh4g@mail.gmail.com>
In-Reply-To: <CAHPuVdULY19T3KD1u5xng_gSA54fY1wAB4xKV+PimAZyhZnh4g@mail.gmail.com>
From: Bob Harold <rharolde@umich.edu>
Date: Thu, 7 May 2020 09:04:30 -0400
Message-ID: <CA+nkc8Cvgtx1cD9p0uVyscvaRpg7NaxA0s+LDnYavD+a00LKkQ@mail.gmail.com>
To: Shumon Huque <shuque@gmail.com>
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="000000000000208adc05a50e862f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/G-flN_5Zr2eLgQeDesdUbBsuvjI>
Subject: Re: [DNSOP] 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: Thu, 07 May 2020 13:04:56 -0000

On Thu, May 7, 2020 at 8:34 AM Shumon Huque <shuque@gmail.com> wrote:

> 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 also support adoption and will review/contribute etc.
>
> 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.
>>
>
> Yup.
>
> > 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 :-{
>>
>
> Yes, unfortunately I concur. My experience recently deploying DNSSEC
> for a large organization made it clear to me that even recent versions of
> mature DNS implementations often have a variety of operationally
> impacting DNSSEC bugs.
>
> 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"?
>>
>
> RFC 6781 Section 4.4.2 (Signature Validity Periods) does mention having
> a reasonable signature inception offset, but recommends no value. It does
> not mention a signature expiration skew. It would be good to treat this
> subject in the document. Personally, I would prefer a fixed value (~ 5 to
> 10 minutes) rather than a percentage. Otherwise, the validator may be using
> a possibly unacceptably small or large skew values depending on the
> validity
> interval.
>

I agree.  The amount a clock is likely to be out of sync is not related to
the signature lifetime in any way.  A fixed value based on likely clock
skew or operational experience would be better.
(Just my opinion, not meaning to sound like an authority on the subject.)

-- 
Bob Harold



>
> > 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.)
>>
>
> As the spec is currently written, yes, the DNSKEY RRset will give this
> information.
>
> Shumon
>
>