Re: [DNSOP] proposal: Covert in-band zone data

Tony Finch <dot@dotat.at> Tue, 09 July 2019 13:24 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 1D0EF12015B for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 06:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=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 eRnsSpjxCude for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 06:24:16 -0700 (PDT)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (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 C30D4120159 for <dnsop@ietf.org>; Tue, 9 Jul 2019 06:24:16 -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]:57160) by ppsw-41.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hkq6Q-000Z84-Rv (Exim 4.92) (return-path <dot@dotat.at>); Tue, 09 Jul 2019 14:24:14 +0100
Date: Tue, 09 Jul 2019 14:24:14 +0100
From: Tony Finch <dot@dotat.at>
To: Joe Abley <jabley@hopcount.ca>
cc: Witold Krecicki <wpk@isc.org>, dnsop@ietf.org
In-Reply-To: <C467FE93-F6CE-4DB4-80E8-654B1485A1F6@hopcount.ca>
Message-ID: <alpine.DEB.2.20.1907091422060.8402@grey.csi.cam.ac.uk>
References: <20190706213024.GA56650@isc.org> <CAJhMdTMwCiAS+S_j-i3BXPZ=G1zVhAq+YKH07RsDWRgezPhejg@mail.gmail.com> <caa695e7-21e6-9c41-1814-1f4c1d64df7f@isc.org> <CAJhMdTPK3iqg4sF0Kr+jGAXTf2MZ8FAP0DgwQw1kVBHa65wTNA@mail.gmail.com> <191886397.1948062.1562455685612.JavaMail.zimbra@isc.org> <CAJhMdTNvO=TjNUV=6wHwLJB_c+tqwk4zY24jGbi5a0SqdSUsag@mail.gmail.com> <561203a3-7fd9-94cc-5b13-3639b123f8e2@isc.org> <C467FE93-F6CE-4DB4-80E8-654B1485A1F6@hopcount.ca>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xNRj-VLahhExbKqEtDqNDezUkJc>
Subject: Re: [DNSOP] proposal: Covert in-band zone data
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, 09 Jul 2019 13:24:19 -0000

Joe Abley <jabley@hopcount.ca> wrote:
>
> There is hence an operational risk that data will leak (e.g. by
> configuration changes, software downgrades that are pragmatic
> necessities, side systems that publish zone data in ways other than the
> DNS).
>
> By keeping data that is already exchanged over a (manual) out-of-band
> channel separate, and not packaging them up with zone data, the existing
> segregation of private vs. public is preserved and the task is simply to
> automate a process that is currently manual.

Yes. It might make sense to put secret keys in catalog zones.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Cromarty, Forth, Tyne: South 3 to 5, becoming variable 3 or less. Smooth or
slight. Occasional rain, fog patches. Moderate, occasionally very poor.