IETF Logo Mail Archive

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

Witold Krecicki <wpk@isc.org> Mon, 08 July 2019 20:05 UTC

Return-Path: <wpk@isc.org>
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 84DE7120090 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 13:05:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_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 6J1E40d2mWC3 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 13:05:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 CE5B91202C3 for <dnsop@ietf.org>; Mon, 8 Jul 2019 13:05:17 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AF1183AB01F; Mon, 8 Jul 2019 20:05:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A47F1160051; Mon, 8 Jul 2019 20:05:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9445116006B; Mon, 8 Jul 2019 20:05:17 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tuoK8Zh9hsVM; Mon, 8 Jul 2019 20:05:17 +0000 (UTC)
Received: from [192.168.69.142] (unknown [31.179.189.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DACEB160051; Mon, 8 Jul 2019 20:05:15 +0000 (UTC)
To: "Wessels, Duane" <dwessels@verisign.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>
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> <BCD5A218-CF1A-4569-B8A2-7BC8B499CC4B@verisign.com>
From: Witold Krecicki <wpk@isc.org>
Message-ID: <a0309614-bd25-08d4-003d-4615779910f6@isc.org>
Date: Mon, 08 Jul 2019 22:05:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <BCD5A218-CF1A-4569-B8A2-7BC8B499CC4B@verisign.com>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gbD-wOwTlR-4H9mxjSecj6u8yQQ>
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 20:05:28 -0000

W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
> 
> 
>> 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.

One more thing - this feature is intended for operators, not for regular
users. We should have more tolerance for shootfooting features there.

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

As I understand ZONEMD main purpose is to verify the full content of the
zone, mainly for zone transfer. In that case, I'd include COVERT records
- as the clients who can transfer the zone using XFR will also be able
to transfer COVERT records. (but I'm not stuck to that opinion).

Witold

v2.23.0 | Report a Bug | By Email