[secdir] Secdir last call review of draft-ietf-dnsop-extended-error-14

Catherine Meadows via Datatracker <noreply@ietf.org> Tue, 31 March 2020 14:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE1A3A2288; Tue, 31 Mar 2020 07:59:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Catherine Meadows via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-dnsop-extended-error.all@ietf.org, dnsop@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158566679527.28397.11447221654478370153@ietfa.amsl.com>
Reply-To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Date: Tue, 31 Mar 2020 07:59:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/TOH5k61BzO1C1GxO3nTGGQF0ops>
Subject: [secdir] Secdir last call review of draft-ietf-dnsop-extended-error-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 14:59:55 -0000

Reviewer: Catherine Meadows
Review result: Has Issues

This ID defines an extensible method to return information about the cause of
DNS errors.  It extends both the type of response that can contain error
messages and the type of messages that can be returned, and includes mechanisms
that can be used to add more as needed.

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.