IETF Logo Mail Archive

Re: [DNSOP] zonemd/xhash versus nothing new

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 01 August 2018 16:14 UTC

Return-Path: <paul.hoffman@vpnc.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 5628F129C6B for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 09:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lwqZRFs-6pMF for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 09:14:51 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 129E8126F72 for <dnsop@ietf.org>; Wed, 1 Aug 2018 09:14:51 -0700 (PDT)
Received: from [10.32.60.131] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w71GEQEX018830 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Aug 2018 09:14:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.131]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Petr Špaček <petr.spacek@nic.cz>, Tony Finch <dot@dotat.at>
Cc: dnsop@ietf.org
Date: Wed, 01 Aug 2018 09:14:42 -0700
X-Mailer: MailMate (1.11.3r5509)
Message-ID: <A693B300-38E7-40A1-9ED9-358B8DD1B9F8@vpnc.org>
In-Reply-To: <45f16f82-4a06-b194-a6e5-da0a230527c0@nic.cz>
References: <alpine.LRH.2.21.1807271758580.22024@bofh.nohats.ca> <alpine.DEB.2.20.1807301424400.3596@grey.csi.cam.ac.uk> <a6226b2d-957a-7953-3a17-67a7282984bb@nic.cz> <alpine.DEB.2.20.1807311549150.3596@grey.csi.cam.ac.uk> <45f16f82-4a06-b194-a6e5-da0a230527c0@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qCplO5Qr09POferLEGj9NyyOygE>
Subject: Re: [DNSOP] zonemd/xhash versus nothing new
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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, 01 Aug 2018 16:14:52 -0000

Maybe changing RFC 4034 and RFC 4035 to have RRSIGs over 
non-authoritative data is not the right way to go. It could break some 
current validators, and it would be hard to let zones sign some but not 
all of the non-authoritative data. (For example, I could imagine a zone 
owner wanting to sign the child NS records but not the glue records.)

Instead, of the WG wants this functionality, it might be cleaner to 
create a new record that acts like RRSIG but is used only on 
non-authoritative data. Think of it as NONAUTH-RRSIG. We would need to 
define the new RRtype (with a lot of pointers to RFC 4034), how it is 
used to sign (with a lot of pointers to RFC 4035), how authoritative 
servers would include those records in responses, and how validators 
would handle the records (this would probably be the trickiest part).

This would lead to a cleaner upgrade path both for authoritative servers 
and resolvers, and thus maybe make it more palatable to the current 
DNSSEC-using population.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email