IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Tue, 10 September 2019 14:07 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 4FF7B120132 for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 07:07:51 -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 mGFu7HnPBLxo for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 07:07:49 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 7277D120110 for <dnsop@ietf.org>; Tue, 10 Sep 2019 07:07:49 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa4.dc.icann.org (8.16.0.27/8.16.0.27) with ESMTPS id x8AE7lbE028138 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dnsop@ietf.org>; Tue, 10 Sep 2019 14:07:48 GMT
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 Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Sep 2019 07:07:46 -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; Tue, 10 Sep 2019 07:07:46 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: IETF DNSOP WG <dnsop@ietf.org>
Thread-Topic: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs
Thread-Index: AQHVZ+EedxViVgeW7EudOFwY+zk2yA==
Date: Tue, 10 Sep 2019 14:07:45 +0000
Message-ID: <AFE92D06-8418-4451-A827-D5656C83B796@icann.org>
References: <EA557043-34D1-43EA-B750-4A17CFC6BE50@icann.org> <ybl36h4aj8x.fsf@w7.hardakers.net>
In-Reply-To: <ybl36h4aj8x.fsf@w7.hardakers.net>
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: <4DE53B976F9B7A47B005F701846E5D76@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-10_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cp1m5s1mSQWE_6VVH23KnrL5zGM>
Subject: [DNSOP] 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: Tue, 10 Sep 2019 14:07:51 -0000

On Sep 9, 2019, at 9:05 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:
> 
> Paul Hoffman <paul.hoffman@icann.org> writes:
> 
> Hi Paul,
> 
> Thanks for the comments and good suggestions.  Responses below inside my
> todo list of action:
> 
> 12 Paul Hoffman
> ===============
> 
>  Greetings again. The changes here generally help the document, but
>  they also highlight some of the deficiencies. A few comments on the
>  current draft:
> 
> 
> 12.1 NOCHANGE what error codes?
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  - The spec does not say anything about the kinds of responses where it
>  is allowed to send particular extended error codes. For example, if a
>  response has an RCODE of NOERROR, what does it mean for it to also
>  have a EDE? Or if the RCODE is FORMERR, can it have an EDE that
>  relates to DNSSEC validation failure? The exact semantics for the
>  receiver need to be specified.
> 
>  + The EDE was specifically meant to be an "addition" to an existing
>    reply of *any* RCODE, including NOERROR codes.  There is no
>    restriction about when you might include one.  Similarly, it makes
>    no sense for some codes to be returned for some RCODES, but any good
>    receiver shouldn't segfault either.  I don't think we can specify
>    all potential combinations in any meaningful way.

Being silent on this is also bad. Proposed text for the introduction:

This document does not allow or prohibit any particular extended error codes and information be matched with any particular RCODEs. Some combinations of extended error codes and RCODEs may seem nonsensical (such as resolver-specific extended error codes in responses from authoritative servers), so systems interpreting the extended error codes MUST NOT assume that a combination will make sense.

Having said that, I think not having restrictions on which EDE can be used with which RCODE with systems in particular roles is actively dangerous. We know that software developers *will* make such assumptions, and attackers will use those wrong assumptions in the future.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email