Re: [DNSOP] zonemd/xhash versus nothing new

Joe Abley <jabley@hopcount.ca> Wed, 01 August 2018 16:57 UTC

Return-Path: <jabley@hopcount.ca>
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 6A3CA130E58 for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 09:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 i4GEsJomrRNF for <dnsop@ietfa.amsl.com>; Wed, 1 Aug 2018 09:57:49 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 41DF4130DDF for <dnsop@ietf.org>; Wed, 1 Aug 2018 09:57:49 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id d9-v6so10621085itf.2 for <dnsop@ietf.org>; Wed, 01 Aug 2018 09:57:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Vc1dWy2M/L3sAEnvmUwd2dKKefdd2z6GsrDMfvxhiM=; b=GUQ+y7jzSsvfwmVTxXNreZRA4qKq96SwsnasN8pVrHe5ICSyHCcA/TUhPuuch049sG Au2iDtPouPP2JtwP5inFtUrHTys9c2f/NhnLw+ITLDYTrCNRB0suZfJqOCMbmTJNYnRh N4cSlisfbdxcxzTik2XjwAJHdqSb0618FO1O4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2Vc1dWy2M/L3sAEnvmUwd2dKKefdd2z6GsrDMfvxhiM=; b=fOSUjgA+4T/raO7JGYhEpHKFUFOnXtiS1nmoTju/V/s2Hnk1FIqmmlKDMsGu8xGive 42ZESfddbdjpz/TDDsBLldWk72TowmjyV6vGgMbxGuJMh3eDVIGcBtzFeIFZ0Dq1vKf8 ZHEudy1ml72OIjr5ck+7svpluHW0340KBG6dkTIV8ZZGCxmIvvJTNHGC2JYLKppFsPkZ EubAV5w5a7skKAQTK2Vd965dHZzYdiLdg2hiPYVBj+w2shbtVppJyp7ZHY4jV0eWcrye ZL7lZ7XSmpgZm8mWkeqTddDNqX7wfsw3aUgWR7HJ5cA6wb4Hhwb9X/hVsZW8zTG3vf7O bJ3A==
X-Gm-Message-State: AOUpUlFvWc0jVaHAnKgyjNXhhxpWy728IvHo+KY+TZV3ZstB2EjEwFAz mhk+rfzrL3FAiyj0g7JTJblydvfaMYo=
X-Google-Smtp-Source: AAOMgpd9b56epeim7L/mXl/3P7/roKKLefNQJf7NzW0oH74leyH2FPbQcRpc+BFo92nteULBvBrJxw==
X-Received: by 2002:a24:2e58:: with SMTP id i85-v6mr4179555ita.32.1533142668456; Wed, 01 Aug 2018 09:57:48 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:308e:160:c02c:2494? ([2607:f2c0:101:3:308e:160:c02c:2494]) by smtp.gmail.com with ESMTPSA id 200-v6sm3197527itk.12.2018.08.01.09.57.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 09:57:46 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (15G77)
In-Reply-To: <A693B300-38E7-40A1-9ED9-358B8DD1B9F8@vpnc.org>
Date: Wed, 1 Aug 2018 12:57:45 -0400
Cc: =?utf-8?Q?Petr_=C5=A0pa=C4=8Dek?= <petr.spacek@nic.cz>, Tony Finch <dot@dotat.at>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <58FBE4A0-1278-475B-854C-CCEBE6F7F109@hopcount.ca>
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> <A693B300-38E7-40A1-9ED9-358B8DD1B9F8@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2g9JPeVdoA1XmLIb5hhOoKnHwh0>
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:57:52 -0000

Hi Paul,

I agree that it would be foolish to change 4034/4035 without understanding the implications of doing so (e.g. breaking validators).

However, it's possible that it would be a fairly minor semantic change, e.g. if signing records with an owner name below a zone cut was optional and if validator code paths were not much affected (they could either validate when they saw the RRSIG or ignore the RRSIG, either way it's possible that things would not break).

Before the idea of using RRSIGs to sign records that are currently specified not to be signed is thrown away, is it perhaps worth exploring it a little more deeply?


Joe

> On Aug 1, 2018, at 12:14, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> 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
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop