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

[Wes Hardaker <[e-mail]>]

Catherine Meadows via Datatracker <[e-mail]> 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