IETF Logo Mail Archive

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

Joe Abley <jabley@hopcount.ca> Tue, 09 July 2019 13:41 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 D16481200EC for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 06:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yAsV25R9oyYa for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 06:41:13 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 0D44812007C for <dnsop@ietf.org>; Tue, 9 Jul 2019 06:41:13 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id j5so23847379ioj.8 for <dnsop@ietf.org>; Tue, 09 Jul 2019 06:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KZ/vyh0aQxtV0wGvnvqHwtnk2riowQ+F+oMt+jmu3Tg=; b=KhQiVYH+DqT9UPGSaRDtT6GUSWl1hzdoj57QHZ3eh034kIOVqyk8sGenE6NDxCjH4i pCNAVRqz4Uq6O9dlq5OCZIpuLIPSrdvfZ8wnPTIzbjHYNgkJI8/LqcmNc28gx/FEXAWf WotJjoaeduAAON6nzFmmSR9TjpAJDKpxnq+UA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KZ/vyh0aQxtV0wGvnvqHwtnk2riowQ+F+oMt+jmu3Tg=; b=R5L2n7JCERB1+nXMD5kVZvFazJVXlRMHXbnILbPlt32raZQGl4s/PtnhnnBUyC8ZKm fkdOUkUO0mwNDvi/cskduWriYVq/35bCvoOtoszwXT0BxzXrFZOnLMfSQcHUS1+6KHae PjvfFRpwSjIgB1Ixv9AIfCRBWhKtEc+CYk8YoaQJOo81JJjbIeV82ZHSu+2zYrUsR9Pg ADaeYPACaIv1E1Vgn5lWUlHJfzPo/kybudoWMeQv836S/7nZI5qhusfvDU8Rp5RlLglT WJOPKC+HHCmhyCwbjyVyHYBAhS+xcVkVOibCDVRFXoXXiaqyI5dG+PjpKe0pgg/DeiMe /E3w==
X-Gm-Message-State: APjAAAXdggZWwAcV4T4g+Mz8T6JZGHno5eKekLGB2vRHcq1/ClZcXgNE ZJK0lQemZt7tfWjUzYqRhWF9vQ==
X-Google-Smtp-Source: APXvYqxBbvdDGkm1IZKST7jbCSryGLvmJJXHLLWOGKLnPT399o/Td7xNVVb1ZUK7Wxeb3O+HKsDnjQ==
X-Received: by 2002:a6b:3b03:: with SMTP id i3mr25458631ioa.302.1562679672108; Tue, 09 Jul 2019 06:41:12 -0700 (PDT)
Received: from [192.168.1.50] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id q15sm19190817ioi.15.2019.07.09.06.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 06:41:11 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <7D5B98BD-AA58-499F-8DDF-ADFEF5276CD7@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_9BD4EED8-0CDF-48FF-940F-F29409A79673"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 09 Jul 2019 09:41:09 -0400
In-Reply-To: <alpine.DEB.2.20.1907091422060.8402@grey.csi.cam.ac.uk>
Cc: Witold Krecicki <wpk@isc.org>, dnsop@ietf.org
To: Tony Finch <dot@dotat.at>
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> <alpine.DEB.2.20.1907091422060.8402@grey.csi.cam.ac.uk>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sGk70SgGiwF6q34TUuxZDFNTiKo>
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:41:14 -0000

Hi Tony,

On 9 Jul 2019, at 09:24, Tony Finch <dot@dotat.at> wrote:

> 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.

My sense is that there are far more examples today of people using REST interfaces to provision DNS services than there are people using catalogue zones, but I agree, catalogue zones are a category of the kind of out-of-zone signalling I'm suggesting.

(I'm agreeing to your agreement \ to make the point that just because catalogue zones use the DNS as a substrate, they're not in-band in the sense of the original proposal.)


Joe

v2.23.0 | Report a Bug | By Email