[DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt

Mark Andrews <marka@isc.org> Sat, 20 July 2024 22:21 UTC

Return-Path: <marka@isc.org>
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 E235BC14F60A for <dnsop@ietfa.amsl.com>; Sat, 20 Jul 2024 15:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="fWBcPwx7"; dkim=pass (1024-bit key) header.d=isc.org header.b="nvpt682f"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT37dWrCYqAd for <dnsop@ietfa.amsl.com>; Sat, 20 Jul 2024 15:20:58 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF812C14F5FC for <dnsop@ietf.org>; Sat, 20 Jul 2024 15:20:58 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id DA9013AB274; Sat, 20 Jul 2024 22:20:57 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org DA9013AB274
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721514057; cv=none; b=lcv2aotwjLtCyXx1wtTMQWL3553OqeSrQ7zMum7Kx0ZcJl6loaoxMoHcv8JIR224IS74BPp3jMrKCeGKNan/l8QeMML903Ebw3RN94HtVC1O/v4f+doOiXRl9pBv+Tfhy6rV9oLJk56jna4oTyEkuWEW8zP7D/GimCOeg8KM3Ng=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721514057; c=relaxed/relaxed; bh=efUcYOTGzyyKpn6xDlR9RVxJtItooi2xYbmE1hTykzU=; h=DKIM-Signature:DKIM-Signature:From:Mime-Version:Subject:Date: Message-Id:To; b=HPOyyudkrXLGpbkzhOBZp4om9c9LSZRHi8TYN8oytomQHWh6BD3yazIwOPHh+SkefD9YJFhXUVE0WldspJrPvZP9TN9NN/f+cDyMDp+YmyZV+IXj6ggpdvgP2qMbN/x8omSe9YFdrO8BrlXfEeijq8zTaHAtQh/opEgvBcvzo3c=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org DA9013AB274
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1721514057; bh=x1nu2/KJ5lBfltpG9iwjt+QbakP5bYpovqka3A4qJ98=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=fWBcPwx7vunLqcx2lO2qgjYishAbhOelLojj37g3FxRIUVfnFafzcix4+N1R1WWv2 mvwG/gIumvpJ3waJZ2kOLYehHwcRY5HhzEpbC5dG2aTmqspgFq/UMOmY9G/wMF2/yy d2hFS+imAQ1HqgNwU7r22bz8p3Asukcsy0lBq1YU=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id D645ADE1D61; Sat, 20 Jul 2024 22:20:57 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id B4D5BDE2333; Sat, 20 Jul 2024 22:20:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org B4D5BDE2333
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1721514057; bh=efUcYOTGzyyKpn6xDlR9RVxJtItooi2xYbmE1hTykzU=; h=From:Mime-Version:Date:Message-Id:To; b=nvpt682fHtf11BjMiYzSmmkA+2nWI8NFXxn27leFNe7pljKQnlFibuYtTFbWIvcLc XkgrW/UCniY0cLHZT86wq2GzM5nybpbz6GeMILtGjaYcySkUi8wgildm70taxdtQ1J hZeo4Zj08jnfBlKL+tHgxHHj3c8EOVphLfvYbYk0=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id FxUNKPleTEfW; Sat, 20 Jul 2024 22:20:57 +0000 (UTC)
Received: from smtpclient.apple (unknown [103.110.142.71]) by zimbrang.isc.org (Postfix) with ESMTPSA id 7F89BDE1D61; Sat, 20 Jul 2024 22:20:57 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Mark Andrews <marka@isc.org>
Mime-Version: 1.0 (1.0)
Date: Sun, 21 Jul 2024 08:20:45 +1000
Message-Id: <91EFD619-1F1E-4E5F-8BCC-4527E49C0B83@isc.org>
References: <659a0f2a-eb82-4769-ad80-63e4f3a24978@nlnetlabs.nl>
In-Reply-To: <659a0f2a-eb82-4769-ad80-63e4f3a24978@nlnetlabs.nl>
To: Yorgos Thessalonikefs <yorgos@nlnetlabs.nl>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: PDNVHVSEAHL43RJFKJ3A5CYXH5C4IWYU
X-Message-ID-Hash: PDNVHVSEAHL43RJFKJ3A5CYXH5C4IWYU
X-MailFrom: marka@isc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Fwd: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ftUg5PkmhQPCZ4cQvFX_fwF5CGY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

DS is the wrong logical point to signal dry run or at least there should also be a key flag otherwise a parent can downgrade the security of zones that don’t want dry run semantics.  Additional validation doesn’t require the DS to be present. It is only required to validate the DNSKEY RRset.
-- 
Mark Andrews

> On 17 Jul 2024, at 00:35, Yorgos Thessalonikefs <yorgos@nlnetlabs.nl> wrote:
> 
> Dear dnsop,
> 
> We submitted a new version of the "dry-run DNSSEC" draft.
> This work was reinitiated now that RFC9567 (DNS Error Reporting) is a standard document and my plan to incorporate it into Unbound during the IETF120 Hachathon.
> 
> This update mainly addresses the following feedback we got from IETF114 and the mailing list:
> 
> ** Burn a bit of the DS Type Digest Algorithms **
> The difference between a dry-run DS and a normal DS will be the Type Digest Algorithm. There will be a dry-run equivalent value for normal digest algorithms. The document currently only specifies one dry-run DS Type Digest Algorithm (for SHA256) but this could change in a later revision to generally use the most-significant bit for this distinction.
> 
> This results in static lengths for each dry-run DS Type Digest Algorithm.
> 
> 
> ** NOERROR reports **
> The idea of an upstream to signal that it would like NOERROR reports sent to the reporting agent (from RFC9567), was going to be included in that RFC but with no concrete use-case at the time it was left out.
> NOERROR reporting is definitely a requirement for this draft since a zone operator would appreciate a signal that notices the existence of dry-run validators with no errors to report.
> 
> Currently it is described as an unsolicited EDNS option next to the Report-Channel but future revisions could treat generation of NOERROR reports as implied in the presence of dry-run DSes.
> 
> 
> We are looking forward for any feedback either here on the mailing list or in person in Vancouver.
> 
> Best regards,
> -- Yorgos
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-02.txt
> Date: Mon, 08 Jul 2024 13:12:06 -0700
> From: internet-drafts@ietf.org
> To: Roy Arends <roy.arends@icann.org>, Willem Toorop <willem@nlnetlabs.nl>, Yorgos Thessalonikefs <yorgos@nlnetlabs.nl>
> 
> A new version of Internet-Draft draft-yorgos-dnsop-dry-run-dnssec-02.txt has
> been successfully submitted by Yorgos Thessalonikefs and posted to the
> IETF repository.
> 
> Name:     draft-yorgos-dnsop-dry-run-dnssec
> Revision: 02
> Title:    dry-run DNSSEC
> Date:     2024-07-08
> Group:    Individual Submission
> Pages:    14
> URL: https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.txt
> Status: https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
> HTML: https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-02.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec
> Diff: https://author-tools.ietf.org/iddiff?url2=draft-yorgos-dnsop-dry-run-dnssec-02
> 
> Abstract:
> 
>     This document describes a method called "dry-run DNSSEC" that allows
>     for testing DNSSEC deployments without affecting the DNS service in
>     case of DNSSEC errors.  It accomplishes that by introducing new DS
>     Type Digest Algorithms that when used in a DS record, referred to as
>     dry-run DS, signal to validating resolvers that dry-run DNSSEC is
>     used for the zone.  DNSSEC errors are then reported with DNS Error
>     Reporting, but any bogus responses to clients are withheld.  Instead,
>     validating resolvers fallback from dry-run DNSSEC and provide the
>     response that would have been answered without the presence of a dry-
>     run DS.  A further EDNS option is presented for clients to opt-in for
>     dry-run DNSSEC errors and allow for end-to-end DNSSEC testing.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org