IETF Logo Mail Archive

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

Joe Abley <jabley@hopcount.ca> Fri, 02 August 2019 16:28 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 D7A98120687 for <dnsop@ietfa.amsl.com>; Fri, 2 Aug 2019 09:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 mb1I1irOp0KH for <dnsop@ietfa.amsl.com>; Fri, 2 Aug 2019 09:28:29 -0700 (PDT)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 41A9312068A for <dnsop@ietf.org>; Fri, 2 Aug 2019 09:28:29 -0700 (PDT)
Received: by mail-io1-xd43.google.com with SMTP id e20so20477741iob.9 for <dnsop@ietf.org>; Fri, 02 Aug 2019 09:28:29 -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=x2OIEWImDPQ9OFskZ4P4gO5rVdpsJoq3OwdxOd842CA=; b=ZjnQONIWspHiSbCNDDeoq7KD/0M/nF+6GSk+zaMdrXZa1+jwioX1tbmLj6FtpFUry5 J3VBXoSs3gIcF7kWeRxNDnslxVIIDRN6AunOCSGWJEXP9ZFn5HSWu+5vDa+LpuaFiC3t OUaKLJ301VAJXtLo7dlMZOyF2JdzHDBpva7T4=
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=x2OIEWImDPQ9OFskZ4P4gO5rVdpsJoq3OwdxOd842CA=; b=sJdRFgj5E3sANdY4GMl+Uw7aF+t9lh6BONBVZ2G65IHzJsNkMdPjC7EFLZaKnGRR37 8hl0XwvX2la6ebEOEyd0wm5Ypbs9EIWJWmveu5iSQ/PK+YzVnuikvL0c5KPVXZZF/vc+ 7kPtvp7UAj4n5geKTUNbdSsq22jCw5yLr4BwH4GkIooQwpuCen6ccY0nnLKrui7fZaGl HmXDlXahtc4U4A3boWc/JB2nFgXZHRICFBuJMWQgKR54Msm6wnreqI9XDuoTiqES5KdA YpLDKKyuPl2fUWti5EDCVyxsVXHkfQ7anvadcfN2sdtzLgm9E3RJPCc7pVGmoR5UKzxp AnNQ==
X-Gm-Message-State: APjAAAVd4PoCDpdKG39uGvsl5F0OPpgLfLx+S/FK5vJfQVqFEPPi+bS2 T3v5p/OEHtdmCXwYALa3at2Qhl32hHpNTA==
X-Google-Smtp-Source: APXvYqyCZuZgXY/PnKej0WAY7aaxnar/ebOstM0H/IO8epZhhy+OgfM1NzqibRpv9c7MCsS7Caf7pQ==
X-Received: by 2002:a02:5185:: with SMTP id s127mr69583356jaa.44.1564763308302; Fri, 02 Aug 2019 09:28:28 -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 p25sm61533872iol.48.2019.08.02.09.28.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Aug 2019 09:28:26 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <3CBF15C5-8378-45B5-BF25-ACB014A2788D@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_F939ECE5-CF87-49B4-B3B7-AF731976B660"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 02 Aug 2019 12:28:25 -0400
In-Reply-To: <91c0669e-66b5-05d6-d788-59aea804a13e@isc.org>
Cc: Paul Ebersman <list-dnsop@dragon.net>, dnsop@ietf.org
To: Witold Krecicki <wpk@isc.org>
References: <20190706213024.GA56650@isc.org> <alpine.BSF.2.21.9999.1907221704030.7062@bikeshed.isc.org> <CAN6NTqymm6+OMet0sMZC0Ms5E_5mj_nwONk3fR19HwgWXYNB4Q@mail.gmail.com> <alpine.LRH.2.21.1907251332070.10708@bofh.nohats.ca> <20190725183051.33DA315BFD9D@fafnir.remote.dragon.net> <alpine.BSF.2.21.9999.1907301916050.7062@bikeshed.isc.org> <20190730200859.A424215E6AD4@fafnir.remote.dragon.net> <alpine.BSF.2.21.9999.1907302009500.7062@bikeshed.isc.org> <20190730201628.1496015E6BFA@fafnir.remote.dragon.net> <2b2a0e4d-3720-b88c-6377-195117896e8f@isc.org> <20190802143247.A9E251601056@fafnir.remote.dragon.net> <91c0669e-66b5-05d6-d788-59aea804a13e@isc.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Wo6BWDVWCSPiGfIum2D_cRicxA4>
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: Fri, 02 Aug 2019 16:28:31 -0000

Hi Witold,

On 2 Aug 2019, at 10:46, Witold Krecicki <wpk@isc.org> wrote:

> They should fail to load the zone as it will contain RRs that it does
> not understand. As long as they won't serve covert records to general
> public - I don't really care.

Standard behaviour is to handle opaque types. You're speculating about the broad range of possibly non-standard behaviour and deciding that anything that is non-standard will exhibit one particular kind of behaviour. I think that's the opposite of what we would normally attribute to "non-standard".

I continue to think that taking a protocol (DNS) and deployed implementations (nameservers) that are designed to answer queries and trying to bolt on a backwards-compatible mechanism for carrying data that is not exposed by queries is just a recipe for data leakage. Any data that is really intended not to be disclosed cannot use a mechanism that is almost guaranteed to leak, which means that this proposed mechanism has no real use case.

I am not in favour of this proposal, which I think is camel abuse.


Joe

v2.23.0 | Report a Bug | By Email