IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Evan Hunt <each@isc.org> Sun, 30 July 2017 07:42 UTC

Return-Path: <each@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 30A88129ADA for <dnsop@ietfa.amsl.com>; Sun, 30 Jul 2017 00:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 af7ubUuPD2Ag for <dnsop@ietfa.amsl.com>; Sun, 30 Jul 2017 00:42:57 -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 380C1129AD3 for <dnsop@ietf.org>; Sun, 30 Jul 2017 00:42:57 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 3A067349442; Sun, 30 Jul 2017 07:42:54 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 19D84216C1E; Sun, 30 Jul 2017 07:42:54 +0000 (UTC)
Date: Sun, 30 Jul 2017 07:42:54 +0000
From: Evan Hunt <each@isc.org>
To: Joe Abley <jabley@hopcount.ca>
Cc: Shane Kerr <shane@time-travellers.org>, dnsop@ietf.org, Paul Wouters <paul@nohats.ca>
Message-ID: <20170730074253.GA33522@isc.org>
References: <CADyWQ+Ffu8JOn6co184PC-Uvv4G1qYU3d0ZchupRJEDDmfYKaw@mail.gmail.com> <CAJE_bqf7R7ZW5ixcZdOcaHDso+C5QbtGbz+Z1mOs+p9_C2_cAg@mail.gmail.com> <alpine.LRH.2.21.1707290851010.26738@bofh.nohats.ca> <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EUiliUa60XCjYzArio2NKLO8Rlg>
Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 30 Jul 2017 07:42:58 -0000

On Sat, Jul 29, 2017 at 10:04:06AM -0400, Joe Abley wrote:
> If client behaviour is not supposed to change when you return
> an extended RCODE, why bother returning one?

It's clearly helpful for human debugging.

But, yes, you're correct -- diagnostic information included with a
SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
authentication mechanism such as TSIG, clients should not rely on it or
base policy on it.

Some of the error codes might be trustworthy enough if you're using COOKIE
or TCP; that would enusre at least that it wasn't an off-path forgery. The
ones related to validation I wouldn't trust without a signature, though.

This should be spelled out in more detail in the security considerations.
(And, considering I'm listed as a co-author on this draft, maybe it's time
I earn my keep and submit some text...)

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.

v2.23.0 | Report a Bug | By Email