[DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field
"libor.peltan" <libor.peltan@nic.cz> Wed, 30 March 2022 14:58 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 95DC93A0D02 for <dnsop@ietfa.amsl.com>; Wed, 30 Mar 2022 07:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 jStQk7uukVA8 for <dnsop@ietfa.amsl.com>; Wed, 30 Mar 2022 07:58:23 -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 2A6DF3A0CFD for <dnsop@ietf.org>; Wed, 30 Mar 2022 07:58:22 -0700 (PDT)
Received: from [172.20.6.119] (unknown [172.20.6.119]) by mail.nic.cz (Postfix) with ESMTPSA id CECF41406DA for <dnsop@ietf.org>; Wed, 30 Mar 2022 16:58:19 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1648652299; bh=QXf2CKOWk67zmsfbAAIcjHmtCo6KyXReE7bdzxhyI8k=; h=Date:To:From; b=yLmtjQupQ0mJaqFNSJwT9XQCMDNQ8BdTVlH8bnXTu7gYrXkU3RvzNNJ39MEMlDwMc EOP/BJfJdzTOap9a/KNH8E70FZlXacHMkDvv0Cug7Q6PgrFr0kHcmRf8ht6XyQglEi k3Jq9QxgLNIPmoR1LgT5dZrqnTULfrRg//qsOAxc=
Message-ID: <d6d0f84b-554b-a03e-4132-40b29c09af43@nic.cz>
Date: Wed, 30 Mar 2022 16:58:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: dnsop <dnsop@ietf.org>
From: "libor.peltan" <libor.peltan@nic.cz>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.103.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/elxJkf0oUFGqmVdpszdb5I2oLZM>
Subject: [DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and DS digest field
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, 30 Mar 2022 14:58:29 -0000
Hi dnsop, Yorgos, Willem, Roy, I really like this idea of dry-run DNSSEC. I think it could really help new DNSSEC adopters. The evidently weird thing of the proposal is the displacement of DS digest field into the first byte of DS hash field, in order to free up space for dry-run signalling. This will cause difficulties in human readability of resulting DS. The obvious counter-proposal would be to simply take the most-significant bit of the DS digest field (set to 1 for dry-run), which would take 128 of available DS digest numbers (instead of just one), but wouldn't otherwise introduce any inconsistencies in DS format. As only four are taken so far, it seems viable to me. Should we (dnsop) discuss this specific matter, or even poll? Thanks, Libor
- [DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 and … libor.peltan
- Re: [DNSOP] draft-yorgos-dnsop-dry-run-dnssec-00 … Willem Toorop