Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-14

Wes Hardaker <wjhns1@hardakers.net> Tue, 14 April 2020 22:34 UTC

Return-Path: <wjhns1@hardakers.net>
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 107DA3A11A2; Tue, 14 Apr 2020 15:34:05 -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 g_Djh6wPjRek; Tue, 14 Apr 2020 15:34:03 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69ACA3A11A0; Tue, 14 Apr 2020 15:34:03 -0700 (PDT)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id AE37B2E022; Tue, 14 Apr 2020 15:34:01 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Cc: secdir@ietf.org, Catherine Meadows <catherine.meadows@nrl.navy.mil>, draft-ietf-dnsop-extended-error.all@ietf.org, dnsop@ietf.org, last-call@ietf.org
References: <158566679527.28397.11447221654478370153@ietfa.amsl.com>
Date: Tue, 14 Apr 2020 15:34:01 -0700
In-Reply-To: <158566679527.28397.11447221654478370153@ietfa.amsl.com> (Catherine Meadows via Datatracker's message of "Tue, 31 Mar 2020 07:59:55 -0700")
Message-ID: <yblv9m1u27a.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/15u90kz3WyGLNNRH6cAhLSu7Jmo>
Subject: Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-14
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, 14 Apr 2020 22:34:05 -0000

Catherine Meadows via Datatracker <noreply@ietf.org> writes:

> Reviewer: Catherine Meadows
> Review result: Has Issues

Hi Catherine,

Thanks for the review of the dnsop-extended-error draft.  [and sorry
for the delay in sending this]

> The Security Considerations section mentions some valid points, but it
> is not made clear how they apply to extended DNS error messages (as
> opposed to DNS error messages in general). It first makes the
> non-obvious point that a significant number of clients, when receiving
> a failure message about a DNS validation issue from a validated
> resolver, will seek out an unvalidated server instead.  It is not
> clear to me though whether you think that extending the types of DNS
> error messages available (thus giving more information to the client)
> would help address this problem.  You should say something about this.
> Secondly, it discusses the security implications of the fact that DNS
> error messages are unauthenticated.
> 
> In addition, in the paragraph about the security implications of DNS error
> messages being unauthenticated, you should say whether or not extending the
> types of DNS error messages would improve the situation,   make it worse, have
> no effect,  or is unclear.

You're right that we don't specify what to do in the security
considerations section, though we do earlier in the document.
Specifically it says (at least):

      Applications MUST continue to follow requirements from applicable
      specifications on how to process RCODEs no matter what EDE values
      are also received.

So maybe adding the following sentence to the security section addresses
your issue?

      EDE content should be treated only as diagnostic information for
      network operators and MUST NOT alter DNS protocol processing.

We could add a note as well about the scope of the document, though I
think it can be derived from the above sentence:

      EDE content is not attempting to address the lack security in DNS
      error messages.

-- 
Wes Hardaker
USC/ISI