On Tue, Apr 14, 2020 at 6:35 PM Wes Hardaker <wjhns1@xxxxxxxxxxxxx> wrote:
Catherine Meadows via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dnsop
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
