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

"Wessels, Duane" <dwessels@verisign.com> Mon, 08 July 2019 17:21 UTC

Return-Path: <dwessels@verisign.com>
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 E956812006B for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 10:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 M_vELQrF3F8V for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 10:21:01 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 09DEF1203C0 for <dnsop@ietf.org>; Mon, 8 Jul 2019 10:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8230; q=dns/txt; s=VRSN; t=1562606433; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=LV9Y5KVGgwbCnz39PkUE4xpbi3qZOXTc8l8bXtjjopA=; b=Z+dBvbIK7hal6LO6J5RUWBImJL+7sAwtR7leJNcxQ50GfY6CmkfNTuXJ 9/OZOZEXS/EQMgQHZ2fNOUFO63OlAixvMLgyUGfiwW3c8YAAeiohjWFm/ v8QrcS9kmMYfmQhy0lNxAqyqzTaqYT1YSwdBFhyjRh6L0y/igJJS1wsIu 6PjtkfOLrgWF6MIvxWT9+Ob6Fs9ib87nBgspDGL4e/9Z5WNBI2lexoD1T X4PV5SCoAjFnXK5wo9xuu/9NHgX6JKCeQneJHuj+ffVrimf7z2XcLE9r+ krj314wHhM6NoEEFrdJ5JE/5sQwoZb/IrTZkjMW4XVSQNswMTZyDC0tKJ A==;
X-IronPort-AV: E=Sophos;i="5.63,466,1557187200"; d="p7s'?scan'208";a="10609235"
IronPort-PHdr: 9a23:QhneUh0QBozvYVSCsmDT+DRfVm0co7zxezQtwd8ZseMQLfad9pjvdHbS+e9qxAeQG9mCsbQY06GP6vqocFdDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBAj0OxZrKeTpAI7SiNm82/yv95HJbAhEmSSxbal9IRmqogndq9QajZV/Iast1xXFpWdFdf5Lzm1yP1KTmBj85sa0/JF99ilbpuws+c1dX6jkZqo0VbNXAigoPGAz/83rqALMTRCT6XsGU2UZiQRHDg7Y5xznRJjxsy/6tu1g2CmGOMD9UL45VSi+46ptVRTlkzkMOSIn/27Li8xwlKNbrwynpxxj2I7ffYWZOONjcq/BYd8WQGxMVdtTWSNcGIOxd4sBAfQcM+ZEoYfzpFUOohm/BQawC+zi0TBIimPz3aAgz+gtDR/K0Qo9FNwOqnTUq9D1Ob8cXe+10qbI1i7DYO1S2Tfm8ITDbx4voeyWUrJ2b8Xdx1QkGgTYgVSet4PlJCiV2foJs2iA9OdgS/ygi3QmqwFqozivycEshpPViYISz1DJ7CN0y5s2K92gUEN3fMKoHIFNuyyYOYZ6WN4uTmFmtSogxbALvYa3cDUWxJg92hLSaeCLf5KV7h/sV+udOyp0iXF9dLKxmRm/8lSsx+j5W8au01tHqjFKn9zCu3wTyhPe682KReB580qg2zuC0g7e5+9GLE8pk6fQNoQvzaQqlpUJtETOBir2mELrg6CIbkgk4e2o6/j/YrXhu5+cK5d4igHgPaQqncyyGfk1PBQWUWSG+euyzLLt8kzlTLlUlPE2jLXWsJfAJcQDvKK2GRJa3pw96xalFDem1s4UkmUALFJAYB6Hjo7pNE/SIP3gEPuzn06gnCppyv3IJLHtH5XAI3bZnLruebtx80tcxxAyzdBb6ZJUELYBIPfrV0Dsut3XEAQ5MxeqzObjE9VwzZ0eVnyVAq+YK6PSsFCI5uQ1L+aQY48VvS7xK+I56P72kX85hVgdcLGn3JsPa3C1BfVmI16Fbnb2hdcBC2gKtBIkTOP2kF2CTSJTZ3GqUq0h4DE7E4WmDZ/YS4CsnrOBwCm7EodRZmBcBVCGCW3oeJmcW/cQdCKSJddskj4eWre6T48uyxGvuRT6y7pgNurb5ioYtY/l1Nhp/eHciQs9pnRICJGi0n2KS208vXkFTD4936E39VNlyX+CyqM+hOZXQ499/fRMB00FOIXHwuhhT5jeRwvHc53BHFq5T869DDUqZsw82d4VYkl7Xd6li0aQjGKRH7YJmunTV9QP+aXG0i20fp4lxg==
X-IPAS-Result: A2G9AAAseiNd/zGZrQplHAEBAQQBAQcEAQGBVgQBAQsBhCwKmFwlg2CXDwkBAQEBAQEBAQEDBAEvAQGBS4J1AoJcNwYOAQMBAQEEAQEBAQQBAQECiyyCOikBgmcBAQEBAgF5BQsCAQgOCi4CMCUCBA4FDoMUAYF7rAyFR4RZEIE0AYFQiFqBS4FBPoE4DBOCTD6ELoNSgiYEqlIDBgKCF4Mrgh+OVZd+pG0CBAIEBQIVgWaBe3AVZQGCQZEFco1QgSEBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 8 Jul 2019 13:20:31 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Mon, 8 Jul 2019 13:20:31 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: Witold Krecicki <wpk@isc.org>
CC: "dnsop@ietf.org WG" <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>
Thread-Topic: [EXTERNAL] Re: [DNSOP] proposal: Covert in-band zone data
Thread-Index: AQHVNFKYO7UbQua6wEW9hRWS3r+4laa+hIEAgAADswCAAqQyAIAAEOOA
Date: Mon, 08 Jul 2019 17:20:31 +0000
Message-ID: <BCD5A218-CF1A-4569-B8A2-7BC8B499CC4B@verisign.com>
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>
In-Reply-To: <C467FE93-F6CE-4DB4-80E8-654B1485A1F6@hopcount.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/signed; boundary="Apple-Mail=_7ABF6709-E4C9-416B-AFE3-76A36BA05AE2"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DzD9oee734gRA-clQ7YqJemAdK4>
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: Mon, 08 Jul 2019 17:21:13 -0000


> On Jul 8, 2019, at 9:20 AM, Joe Abley <jabley@hopcount.ca> wrote:
> 
> 
> As far as this particular idea goes, I mentioned before what had given me pause: we're talking about taking a protocol where every RRSet in a zone to date has been public and is made available in DNS responses. Any server that doesn't implement this new mechanism would presumably treat the new covert RRTypes as they would any other unknown/opaque type and make the data public.
> 
> 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.

I share this concern raised by Joe.  I agree that it can be useful to exchange configuration/provisioning data this way, but leaks seem almost inevitable as proposed.

I'll probably regret this, but what about a COVERT class, instead type RR type?

With respect to 2.6. Interaction with ZONEMD, I'd think it should follow handling of DNSSEC.  That is, covert types should not be included in a zone digest.

DW