IETF Logo Mail Archive

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

Chris Thompson <cet1@cam.ac.uk> Fri, 07 December 2018 14:37 UTC

Return-Path: <cet1@hermes.cam.ac.uk>
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 B190E1292AD for <dnsop@ietfa.amsl.com>; Fri, 7 Dec 2018 06:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cam.ac.uk
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 BEzLBbByylkT for <dnsop@ietfa.amsl.com>; Fri, 7 Dec 2018 06:37:33 -0800 (PST)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 4F78E1252B7 for <dnsop@ietf.org>; Fri, 7 Dec 2018 06:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Sender:Content-Type:Mime-Version:References:In-Reply-To: Message-ID:Subject:Reply-To:Cc:To:From:Date:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1EXdX7ZNXPxUajqlaSKf1a1BKPtQ2oJ7rDCwD5gYAtg=; b=nWV+m4CZ4pU/XCLbYQ6lxpGtcd pkl/Schg0tLmNRhI9o+pgMxz/jrzjvIZx51AcVmTDJEF+2U/ggfThnDLVD4dhn4tW5zwY/9blViTO u3sJFIUbTDAmTVG7x/b0avJlHuxuqb01otYbbRDz/tmeMnX0E3S7DTFGAxny8n2NqqLo=;
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56504) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:cet1) id 1gVHFz-000D28-dY (Exim 4.91) (return-path <cet1@hermes.cam.ac.uk>); Fri, 07 Dec 2018 14:37:31 +0000
Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1gVHFz-000290-89 (Exim 4.91) (return-path <cet1@hermes.cam.ac.uk>); Fri, 07 Dec 2018 14:37:31 +0000
Received: from [128.232.253.131] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 07 Dec 2018 14:37:31 +0000
Date: Fri, 07 Dec 2018 14:37:31 +0000
From: Chris Thompson <cet1@cam.ac.uk>
To: Mukund Sivaraman <muks@mukund.org>
Cc: dnsop@ietf.org
Reply-To: cet1@cam.ac.uk
Message-ID: <Prayer.1.3.5.1812071437310.4863@hermes-1.csi.cam.ac.uk>
In-Reply-To: <20181206184149.GA6464@jurassic.lan.banu.com>
References: <20181206144504.GA17780@jurassic.lan.banu.com> <4559130.e78567a6.16784231f73@redbarn.org> <20181206184149.GA6464@jurassic.lan.banu.com>
X-Mailer: Prayer v1.3.5
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="ISO-8859-1"
Sender: Chris Thompson <cet1@hermes.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MxuvYHTc6hcjoqgeFky71Evhu_Y>
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:37:35 -0000

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.

-- 
Chris Thompson
Email: cet1@cam.ac.uk

v2.23.0 | Report a Bug | By Email