[DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error

Edward Lewis <edward.lewis@icann.org> Wed, 02 August 2017 14:56 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 06B7D124207 for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 07:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id s6SQS8BbKLez for <dnsop@ietfa.amsl.com>; Wed, 2 Aug 2017 07:56:33 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A007D120727 for <dnsop@ietf.org>; Wed, 2 Aug 2017 07:56:33 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org ( by PMBX112-W1-CA-1.pexch112.icann.org ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 Aug 2017 07:56:31 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1178.000; Wed, 2 Aug 2017 07:56:31 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
Thread-Topic: Trusting what you see - was Re: [Ext] Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
Thread-Index: AQHTC5+Gjh/LhWYWr0mo/goIazwVqA==
Date: Wed, 2 Aug 2017 14:56:31 +0000
Message-ID: <FEF74B9E-3841-4CEF-9005-187FB9927BC9@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/f.24.1.170721
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3584505391_1665324243"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/X5GaN5cUBr0Pb_Rtf-FtI1RefIg>
Subject: [DNSOP] Trusting what you see - was Re: [Ext] Re: 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: Wed, 02 Aug 2017 14:56:35 -0000

On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" <dnsop-bounces@ietf.org on behalf of shane@time-travellers.org> wrote:

>I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? 

If a receiver can't trust what it gets from the network, you can't run a protocol.  Dead in the water.

No matter what, what a receiver does next will depend on what it gets from the network (or doesn't get/timeout).  That happens now, in an unmanaged way.  IMHO, it would be good to address that (the reactions, as opposed to elaborating on the error).

If you are worried about having trustable error codes, think of a way to secure the channel (like TSIG).  If you are worried and can't secure the channel, then it doesn't matter whether RCODES are extended or not - you have nothing trustable to act upon.  (See: dead in the water.)

Once you have faith that there's usefulness in the error/response code you do receive, then you can design what the reaction is.  (If you are worried, you need to do what is necessary to build the faith or this will not be solvable.)

I sent a long message urging that the response indicate the next step, not so much indicating what went bad.  I won't belabor that - my motivation comes from the observation that many folks are used to "debugging" DNS via query/resposnse as they are not the authorized operator of the answering system.  Extending RCODEs should be about solving the protocol's needs, not about preserving the ability of remote debugging of servers, leave that to the authorized operator.