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

From: Wes Hardaker <[email-masked]>
Date: Tue, 14 Apr 2020 15:34:01 -0700

Catherine Meadows via Datatracker <[email-masked]> 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

---

From: Eric Orth <[email-masked]>
Date: Thu, 16 Apr 2020 13:26:07 -0400

>       network operators and MUST NOT alter DNS protocol processing.

I have similar objections to this as the similar language that was in the
draft before it was changed to the "MUST continue to follow" language
referenced above.

Anything similar to "MUST NOT alter ... processing" is vague over what
constitutes an alteration to the processing.  I think everybody would agree
that you should be able to log EDEs, so it must be unambiguous that doing
so is allowed.  Lots of discretionary room for implementers (especially
stub implementers) to do various things with an EDE while still following
the specs on the important handling of the RCODE as the primary error code.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 17 Apr 2020 14:56:09 -0700

Eric Orth <[email-masked]> writes:

> I have similar objections to this as the similar language that was in the draft
> before it was changed to the "MUST continue to follow" language referenced
> above.
> 
> that you should be able to log EDEs, so it must be unambiguous that doing so is
> allowed.  Lots of discretionary room for implementers (especially stub
> implementers) to do various things with an EDE while still following the specs
> on the important handling of the RCODE as the primary error code.
>  
> 

Hi Eric,

Thanks for the (again) well thought out comments.  Do you have a counter
proposal sentence?

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 17 Apr 2020 14:56:22 -0700

Hi Eric,

Thanks for the (again) well thought out comments.  Do you have a counter
proposal sentence that could be added to the security seciton?

-- 
Wes Hardaker
USC/ISI