[DNSOP] CDS/CDNSKEY RRSet authentication

Tony Finch <dot@dotat.at> Sat, 29 July 2017 21:00 UTC

Return-Path: <dot@dotat.at>
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 F118E131D36 for <dnsop@ietfa.amsl.com>; Sat, 29 Jul 2017 14:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=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 p40QRPyGw_KU for <dnsop@ietfa.amsl.com>; Sat, 29 Jul 2017 14:00:56 -0700 (PDT)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 6798912EB9B for <dnsop@ietf.org>; Sat, 29 Jul 2017 14:00:56 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:40462) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dbYr0-000OkG-dP (Exim 4.89) for dnsop@ietf.org (return-path <dot@dotat.at>); Sat, 29 Jul 2017 22:00:54 +0100
Date: Sat, 29 Jul 2017 22:00:53 +0100
From: Tony Finch <dot@dotat.at>
To: dnsop@ietf.org
Message-ID: <alpine.DEB.2.11.1707292141070.23659@grey.csi.cam.ac.uk>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/W_JNUoiy8FxLsD8jODPkpkBhHBo>
Subject: [DNSOP] CDS/CDNSKEY RRSet authentication
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 29 Jul 2017 21:00:58 -0000

I think I have spotted a lacuna or possibly erratum in RFC 7344.

In section 4.1 bullet 2 it says:

   o  Signer: MUST be signed with a key that is represented in both the
      current DNSKEY and DS RRsets, unless [unusual case]

This allows a setup where

* the DNSKEY RRset contains a ZSK and a KSK

* the DNSKEY RRset is signed by the KSK (of course)

* the CDS and CDNSKEY RRsets are signed by the ZSK (weirdly)

* the parent contains DS records corresponding to both the KSK (of
  course) and the ZSK (weirdly)

In this weird setup the ZSK's DS can't authenticate the delegation (per
RFC 4035 section 5.2) but it does authenticate the CDS/CDNSKEY RRsets.

Is this intended?

Or was RFC 7344 supposed to say something like:

   o  Signer: MUST be signed with a DNSKEY RR that authenticates the
      delegation as described in RFC 4035 section 5.2 or any subsequent
      updates, unless [unusual case]

One particularly relevant update is RFC 4509 which has extra requirements
about ignoring SHA-1 DS records if SHA-2 records are present. Should this
check also apply to CDS / CDNSKEY RRsets?

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth: Cyclonic, mainly west or southwest, 5 to 7. Moderate or
rough. Rain then showers. Moderate or poor, becoming good.