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

On Tue, Apr 14, 2020 at 6:35 PM Wes Hardaker <wjhns1@hardakers.net> wrote:

> 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.
>

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.

>
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>