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

Tim Wicinski <tjw.ietf@gmail.com> Wed, 11 September 2019 00:58 UTC

Return-Path: <tjw.ietf@gmail.com>
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 A22551207FC for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 17:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CMDSWRCxRqu0 for <dnsop@ietfa.amsl.com>; Tue, 10 Sep 2019 17:58:37 -0700 (PDT)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290EB1200E0 for <dnsop@ietf.org>; Tue, 10 Sep 2019 17:58:37 -0700 (PDT)
Received: by mail-oi1-x232.google.com with SMTP id k20so12756831oih.3 for <dnsop@ietf.org>; Tue, 10 Sep 2019 17:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4ZgaG5W0J8By3q/Wh+4lrsS6Bl7NO2Z2oG6schzZ7E4=; b=AHFrmZcjabbzDInJGat4+b+YWdhzNfUMvyET0BmXubF/InKv+DaBJG4mXreRFRHAf5 uXS8YnLG2PpQMG0ROcnilfSNHCearBWS1KjaJRT601tY3K0ZEtvIfImUaLrl2z3idkd6 1Y3/GlMImbOLmZK7o3uWPSMWuniWZJ4u09QPla9UwmvWJJiU9yavA4C++T5/nxjaLF77 ijPaSzfI19aSZalkiZj5mdbLcg7/yWyC5+yZgNVxBp1znmNarKxZcRe1QOC/AQAGaJzo r26bJKX91QcOjmcf0jYUDawg43oK33Vf8jIk5tW7iYbiWG3T0cL+izM/z6BaCOZWomiG 6DNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4ZgaG5W0J8By3q/Wh+4lrsS6Bl7NO2Z2oG6schzZ7E4=; b=rGWX+PmKRe6rYYH2J4tbOHBqkd5UuumsiNgvipuyjjG8ghyPg+AzvmKM3bNJyynt1i Otw/DYvy60GViRTHIvTX8Z+wU4rvlJGEHkGhGT7tHSQe3VI/5W1xwjaABDsQ1dRlWJR8 9oqL0fEnTFuVjyeEJNh2PFXydow6gmjiVCWUOR/CTqMDtpRTcnxWfiqwUDdWPaQFizm6 8xsNV5UrO0c+iuSt6xRgHS0q6YqPTWY60Nke6rZq13hknZJbxW6WIESdxfgBGTeXMiK7 5ljfbVB3Dwp9R/yhH2obX4RTj/OOUvHMfY0/YSo5KYL2Q2yIu5JkWfNM4vEMyaOTHzI+ gpag==
X-Gm-Message-State: APjAAAUydpAli7QtfpEJPXM5nAYC7qLCYu61RKuegk3sfl36WRfd6B3+ HCb5gnA1AzQq78cWwCvVkLECQZiQqUJXqzBqmpV2Ojps
X-Google-Smtp-Source: APXvYqx+ENGMWUJgwP3UlFluylcY2NLFMTVLmXR1k5V3tqQJnjkWVeSs8z8AM0O6WyONhFJWvxt7FXFchAay6x5k5xI=
X-Received: by 2002:aca:c792:: with SMTP id x140mr2078545oif.132.1568163516418; Tue, 10 Sep 2019 17:58:36 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <067589D2-8E7E-47FA-867C-72E266A55D6D@icann.org>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Tue, 10 Sep 2019 20:58:25 -0400
Message-ID: <CADyWQ+EB-eotvTdYwNv5Oo4=-mibdgEgpkQ3yh37orAwp-AgWg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Wes Hardaker <wjhns1@hardakers.net>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000588d0f05923c858d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OnFtOdASm_zOnFWn4sQRwdc6njA>
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 00:58:40 -0000

it sounds to me that a discussion on assumptions with EDEs and RCODES would
be useful in the security considerations section as well.

and Wes, it should be "Receivers MUST be" and not "Receives MUST be" in
your last sentence.

Tim


On Tue, Sep 10, 2019 at 8:43 PM Paul Hoffman <paul.hoffman@icann.org>; wrote:

> On Sep 10, 2019, at 4:02 PM, Wes Hardaker <wjhns1@hardakers.net>; wrote:
> >
> > Paul Hoffman <paul.hoffman@icann.org>; writes:
> >
> >> 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.
> >
> > I think that works.  I extended it with one more sentence:
> >
> >      <t>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.  Receives MUST be able to accept
> >      EDE codes and text in all messages, including even those with a
> >      NOERROR RCODE.</t>
>
> 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.
>
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>