Re: [DNSOP] zone contents digest and DNSSEC stuff

"libor.peltan" <libor.peltan@nic.cz> Tue, 29 September 2020 13:42 UTC

Return-Path: <libor.peltan@nic.cz>
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 48B2B3A0CC7 for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 06:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_NONE=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 5J8_fo3q2dcG for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2020 06:42:10 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386973A0972 for <dnsop@ietf.org>; Tue, 29 Sep 2020 06:42:08 -0700 (PDT)
Received: from [192.168.0.104] (unknown [82.202.71.9]) by mail.nic.cz (Postfix) with ESMTPSA id 2F815140AA2; Tue, 29 Sep 2020 15:42:06 +0200 (CEST)
To: Joe Abley <jabley@hopcount.ca>
Cc: dnsop@ietf.org
References: <4553c77e-9333-1002-d06e-e9ad10857290@nic.cz> <72D9D13F-15E2-4E99-84E7-305CDC5923BA@hopcount.ca>
From: "libor.peltan" <libor.peltan@nic.cz>
Message-ID: <f44f2ead-27b8-2dc1-807d-007e216c278f@nic.cz>
Date: Tue, 29 Sep 2020 15:42:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <72D9D13F-15E2-4E99-84E7-305CDC5923BA@hopcount.ca>
Content-Type: text/plain; charset="iso-8859-2"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JTR752RM6fACn3c4KMCEvta5J5M>
Subject: Re: [DNSOP] zone contents digest and DNSSEC stuff
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: Tue, 29 Sep 2020 13:42:12 -0000

Hi Joe,

Dne 29.09.20 v 15:03 Joe Abley napsal(a):
> The other use case I seem to think you're implying is that a consumer of the signed zone could verify that it was intact using the signed-zone ZONEMD, then strip the DNSSEC RRs and retain the ability to verify that the result was an accurate representation of the unsigned zone using the unsigned-zone ZONEMD. This seems like a slightly odd thing to want to do, but perhaps I'm just not thinking hard enough?
>
>
> Joe

yes, something like this.

My initial thought was that the signer, which converts the un-signed 
zone by adding signatures and keys, might not be able to compute/update 
the ZONEMD record.

It might also be useful, when the zone is only re-signed and otherwise 
unchanged, if the zone checksum was unchanged.

I'm not sure. This is just a thing to be thought of.

I would love if there was a bit flag indicating if the checksum has been 
computed including DNSSEC records, or without them. This would let the 
freedom of choice on the users, while adding some complexity to software 
implementation.

Thanks for consideration,

Libor