Re: [DNSOP] RFC 2136 pre-requisite checks before client authorization checks

Mukund Sivaraman <muks@mukund.org> Fri, 07 December 2018 14:56 UTC

Return-Path: <muks@mukund.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 1D14012D4EB for <dnsop@ietfa.amsl.com>; Fri, 7 Dec 2018 06:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 pUYDK32CpgJr for <dnsop@ietfa.amsl.com>; Fri, 7 Dec 2018 06:56:16 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id C92371252B7 for <dnsop@ietf.org>; Fri, 7 Dec 2018 06:56:15 -0800 (PST)
Received: from jurassic.lan.banu.com (unknown [210.18.173.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 52F7432C0950; Fri, 7 Dec 2018 14:56:14 +0000 (UTC)
Date: Fri, 07 Dec 2018 20:26:11 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Chris Thompson <cet1@cam.ac.uk>
Cc: dnsop@ietf.org
Message-ID: <20181207145611.GA3526@jurassic.lan.banu.com>
References: <20181206144504.GA17780@jurassic.lan.banu.com> <4559130.e78567a6.16784231f73@redbarn.org> <20181206184149.GA6464@jurassic.lan.banu.com> <Prayer.1.3.5.1812071437310.4863@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Prayer.1.3.5.1812071437310.4863@hermes-1.csi.cam.ac.uk>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kl_e-pmi6_mZ5oOoRQFvsGEAL98>
Subject: Re: [DNSOP] RFC 2136 pre-requisite checks before client authorization checks
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, 07 Dec 2018 14:56:18 -0000

On Fri, Dec 07, 2018 at 02:37:31PM +0000, Chris Thompson wrote:
> On Dec 6 2018, Mukund Sivaraman wrote:
> 
> > On Thu, Dec 06, 2018 at 04:29:13PM +0100, p vixie wrote:
> > > It's an error in the specification.
> > 
> > Thank you Paul. That clears it. I asked because BIND follows the RFC to
> > the letter, and an admin may see some log messages that are unexpected
> > for an address that's not in the update ACL.
> 
> This is actually a (long-standing, if rather mild) security exposure.
> By distinguishing the error codes returned for suitably crafted update
> operations, a client not authorised to even query a zone can determine
> the existence or otherwise of names, RRsets, and even specific RRs with
> guessed rdata, within it.

IIRC BIND checks if a client can query the zone before it proceeds with
the update algorithm. Don't know about other implementations.

		Mukund