Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

Paul Hoffman <paul.hoffman@icann.org> Wed, 11 September 2019 14:52 UTC

Return-Path: <paul.hoffman@icann.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 E19A6120132 for <dnsop@ietfa.amsl.com>; Wed, 11 Sep 2019 07:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9RqeJwdOHYNb for <dnsop@ietfa.amsl.com>; Wed, 11 Sep 2019 07:52:32 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 99C1B12012A for <dnsop@ietf.org>; Wed, 11 Sep 2019 07:52:32 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x8BEqNuS010623 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Sep 2019 14:52:23 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Sep 2019 07:52:21 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1473.005; Wed, 11 Sep 2019 07:52:21 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Evan Hunt <each@isc.org>
CC: IETF DNSOP WG <dnsop@ietf.org>, Wes Hardaker <wjhns1@hardakers.net>
Thread-Topic: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Thread-Index: AQHVaGDCN8JHt8mbEEOgT+YEVCbub6cnBZ0A
Date: Wed, 11 Sep 2019 14:52:20 +0000
Message-ID: <6480F70E-4290-4FDD-84CD-7DF92146D098@icann.org>
References: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org> <ybl36h4aj8x.fsf@w7.hardakers.net> <AFE92D06-8418-4451-A827-D5656C83B796@icann.org> <yblzhjbeova.fsf@w7.hardakers.net> <067589D2-8E7E-47FA-867C-72E266A55D6D@icann.org> <20190911052114.GB62502@isc.org>
In-Reply-To: <20190911052114.GB62502@isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FC1E94D3FC0CC24CB93CBD07B9B1E38F@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-11_08:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BFSXSU0M2-rV6UxFF2VJfGrXtuo>
Subject: Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
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: Wed, 11 Sep 2019 14:52:34 -0000

On Sep 10, 2019, at 10:21 PM, Evan Hunt <each@isc.org>; wrote:
> 
> On Wed, Sep 11, 2019 at 12:42:53AM +0000, Paul Hoffman wrote:
>> Thanks. However, I still think this opens a lot of security holes if
>> developers try to be "smart" by assuming that some EDEs only make sense
>> with some RCODEs. If I'm in the rough, I'll be quiet.
> 
> Sorry, I'm a bit slow tonight; can you explain in more detail the
> security hole you foresee, and how Wes's suggestion fails to address
> it?

A simple case:

A developer writes code that assumes that EDE X must go with RCODE Y because the text for EDE X indicates that. The get a response with EDE X and RCODE Z. The code rejects that, and does not act on RCODE Z.

If the WG believes that Wes' text will prevent developers from ever assuming that EDEs need to match RCODEs, that's fine, but I note that TimW suggested that there be a Security Consideration about this as well. 

--Paul Hoffman