Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

Puneet Sood <puneets@google.com> Wed, 23 October 2019 01:49 UTC

Return-Path: <puneets@google.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 365631200CD for <dnsop@ietfa.amsl.com>; Tue, 22 Oct 2019 18:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Ts2rUrCkN6df for <dnsop@ietfa.amsl.com>; Tue, 22 Oct 2019 18:49:28 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 64F69120026 for <dnsop@ietf.org>; Tue, 22 Oct 2019 18:49:28 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id l2so12701180vsr.8 for <dnsop@ietf.org>; Tue, 22 Oct 2019 18:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mliB3Gi7ZG9VinUM7jrT3XjOfQP6atoRIe4TyeY1WN4=; b=mrNZpvAjX2nLOpGhTW75iiW8FR27qeKzG4xupoITpBYTu/wYmfr2og/DxlE7EQ5Nip /a2/qPPMKjT32bmNZPxipKKd1DCjY7e3oMvppVBzI1EbqKUuh16rZACoXDWSD4nqPr7B iNVeUh8w/FrRuoryvfWl66nGzAn2cDMknowjioJ7ye+eTaCz4vKwTAPZ3XsHgOpvOds8 pZpt9iKu0tz61VJlnBtTXD/AlBS2MBaGJ2IUdydd97AANwh4ZrUUAW/YVXOe1yUiJM8K S1lyYdkHrT5Wink6yKM2qhMnVsYrG9UVonYcMihnSg1dZHL7M5yr78Sq1MIHEPk/Ct8/ IH/A==
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=mliB3Gi7ZG9VinUM7jrT3XjOfQP6atoRIe4TyeY1WN4=; b=CtLU49dwvBQjvqksqiYnFbFGqbqrgBG8C8AibpCGvxuEb/2m72IWAl0Y3WHNgPUndO v61GTloBchJT1VTX0/fdsPTsN4/3XkrJTH201HC7XaCo+7LkmIdmzosEM+DKUldsU61D BGtVVDYdxJg7aCusfH2NaV4WBAbnvtNkhQDbQ20DEF/XZYNV2ldeUhNXHXAtesc0And2 KaJMrwvMBK4m2i4M+/Tvu/GwkC/FSlWtUAKdY1uVtPDpw6x8W4IZVc1YzsIsxr3NeOH/ 0b8wDvHGhuvdpTuN8MkLWr8AX5ljONELWWvVrh9pwpd40nGXJinFnOOItu4rbul5jzPC AsJQ==
X-Gm-Message-State: APjAAAWQujdz7sH528DamSMRcPm0NvWGTR17PZ6lgBWjuhBmFzzLiBK4 Zze91I4k3NcznLx/Snz+kMAbBOLGyC8lJP57c8kc3sVd
X-Google-Smtp-Source: APXvYqwzbxEX+bMpmLzToOzZ0j3M/y5cFvw7BqllgE9wi6D7Xiksd9Z8EQ8Q20UnrTRn9UXg5CvfOyutKCky4usBpQU=
X-Received: by 2002:a67:be19:: with SMTP id x25mr3825627vsq.51.1571795366720; Tue, 22 Oct 2019 18:49:26 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+FG7qzPnLkUH7mSBca=1NfXy6YduHD4UdmcfXFjD8xC6g@mail.gmail.com> <CA+9_gVuwAEthi9HU2wdw+Vf+STCwvXr4wOB4PRD_Hej6JPPbuQ@mail.gmail.com> <yblr241z4s8.fsf@w7.hardakers.net>
In-Reply-To: <yblr241z4s8.fsf@w7.hardakers.net>
From: Puneet Sood <puneets@google.com>
Date: Tue, 22 Oct 2019 21:49:14 -0400
Message-ID: <CA+9_gVvqqKwrkM7WYuEGGzfy+DSm3TzwmCDXA+AyyQ3c0Hr8wg@mail.gmail.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QU5qWklvKH9FRnWAJS_u2jHKTfY>
Subject: Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
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, 23 Oct 2019 01:49:31 -0000

Wes,

I read and diffed version 12 but did not find text addressing some of
my comments.

On Fri, Sep 27, 2019 at 7:41 PM Wes Hardaker <wjhns1@hardakers.net>; wrote:
>
> Puneet Sood <puneets=40google.com@dmarc.ietf.org>; writes:
>
> Hi Puneet,
>
> Thanks for the comments.  Responses are inline below in my tracking
> notes below.
>
> 14.5 TODO Puneet Sood
> ~~~~~~~~~~~~~~~~~~~~~
>
>   I got around to review the draft only recently and have made an
>   attempt to avoid points of discussion that have been resolved since
>   IETF Prague. Apologies in advance for any duplicates.
>
>
> * 14.5.0.1 DONE 1. Introduction and background
>
>   Para 2: "A good example of issues that would benefit ..."  Comment:
>   The paragraph leads up to the conclusion that the EDE codes will be
>   helpful to a client to decide between retry and stopping.  Since the
>   consensus is that the EDEs are purely diagnostic, it would be good to
>   reiterate that at the end of this paragraph.
>
>   + Response from Viktor: For the record, while that was
>   "diagnostic" was my take on the purpose of these codes, reading other
>   responses, I am not sure that's yet the consensus view...  I could
>   also live with these being actionable, provided the text is then more
>   clear on how to do that correctly
>
>   If the actions based on these codes are arbitrary choices for each
>   implementation, with not even a clear correspondence with associated
>   RCODEs, that feels like too much rope to me...
>
>   Eric Orth's comment from Sept 17 is also relevant here (no one has
>   responded to it yet). Quoting the last bullet from his response here
>   for reference:
>   [https://mailarchive.ietf.org/arch/msg/dnsop/GTg8wa7lQ-VoBFcp_P5tT4VuQhE]
>   *Something like "applications MUST NOT act on EDE" or "applications
>   MUST NOT change rcode processing" does not seem reasonable to me.  Way
>   too unclear what "diagnostic" processing is reasonable and allowed or
>   not.  And potentially limits applications from doing processing based
>   on very reasonable or obvious interpretations of the received
>   rcode/EDE combinations."
>
>   + Response: Paul H. gave us language to put in both the abstract and
>     introduction to address this.  Let me know if you think it doesn't
>     address this issue.
LGTM

>
>
> * 14.5.0.2 TODO 2. Extended Error EDNS0 option format / forwarding /etc/
>
>   Final para: "The Extended DNS Error (EDE) option can be included in
>   any response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to a
>   query that includes OPT Pseudo-RR [RFC6891]. ..."
>
>   Comment: Given the level of discussion around behavior when
>   sending/receiving the EDE option, there should be some more text
>   giving guidance on behavior.
>
>   a. For recursive resolvers, it may be worth pointing that it is not
>   expected to copy/forward EDE values received from authoritative
>   nameservers to their clients.  b. What is the expectation on caching
>   for the EDE code generated by a recursive resolver in response to a
>   query? My expectation is that it will be cached (if the answer itself
>   is cached) so the next response has the same EDE code.

> c. Truncation:
>   In case a response including the EDE option with EXTRA-TEXT filled in
>   exceeds the effective UDP payload size, what is the desired behavior
>   for the EDE option? Should the EXTRA-TEXT field be left empty in favor
>   of filling in other RR types? Should the response be marked truncated
>   to require a re-query over TCP?

Independent of the decision on EDE forwarding and caching, the I-D
needs to have some guidance for it. The EXTRA-TEXT field may be
obtained from configuration and it is possible that the resulting DNS
message will exceed UDP message size limit in the request.

>
>   This is unlikely for failures but could happen when DNSSEC validation
>   could not be performed due to unsupported digest type.
>
>   + Response: good questions, and I think the WG needs to think about
>     whether to add that much more data.
>
>
> * 14.5.0.3 DONE 3.14 Extended DNS Error Code 13 - Cached Error
>
>   The resolver has cached SERVFAIL for this query.
>
>   Comment: To match the text the name should be "Cached SERVFAIL".
>
>
> * 14.5.0.4 NOCHANGE 5. Security Considerations
>
>   Para 2: "This information is unauthenticated information, and an
>      attacker (e.g a MITM or malicious recursive server) could insert an
>      extended error response into already untrusted data ..."  Comment:
>      Agree with some other comments that this is not relevant since no
>      action is expected to be taken based on EDEs.  Comment: There are
>      ideas in the thread to have links to info in the EXTRA-TEXT and
>      possibly display it to users. I guess the usual warnings to not
>      click on potentially unsafe links apply.
>
>   + Yeah, it really would be remiss to leave out that point.  There may
>     be nothing we can do, but the whole point of a security
>     consideration is to properly disclose any known threats/issues.
I do not see text mentioning this.

Thanks,
Puneet

>
>   Thanks, Puneet
>
>
>
>
> --
> Wes Hardaker
> USC/ISI