Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-extended-error and combinations of EDEs and RCODEs

[Paul Hoffman <[e-mail]>]

On Sep 10, 2019, at 4:02 PM, Wes Hardaker <[e-mail]> wrote:
> 
> Paul Hoffman <[e-mail]> writes:
> 
>> On Sep 9, 2019, at 9:05 PM, Wes Hardaker <[e-mail]> wrote:
>>> 
>>> Paul Hoffman <[e-mail]> writes:
>>> 
>>> Hi Paul,
>>> 
>>> Thanks for the comments and good suggestions.  Responses below inside my
>>> todo list of action:
>>> 
>>> 12 Paul Hoffman
>>> ===============
>>> 
>>> Greetings again. The changes here generally help the document, but
>>> they also highlight some of the deficiencies. A few comments on the
>>> current draft:
>>> 
>>> 
>>> 12.1 NOCHANGE what error codes?
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> 
>>> - The spec does not say anything about the kinds of responses where it
>>> is allowed to send particular extended error codes. For example, if a
>>> response has an RCODE of NOERROR, what does it mean for it to also
>>> have a EDE? Or if the RCODE is FORMERR, can it have an EDE that
>>> relates to DNSSEC validation failure? The exact semantics for the
>>> receiver need to be specified.
>>> 
>>> + The EDE was specifically meant to be an "addition" to an existing
>>>   reply of *any* RCODE, including NOERROR codes.  There is no
>>>   restriction about when you might include one.  Similarly, it makes
>>>   no sense for some codes to be returned for some RCODES, but any good
>>>   receiver shouldn't segfault either.  I don't think we can specify
>>>   all potential combinations in any meaningful way.
>> 
>> Being silent on this is also bad. Proposed text for the introduction:
>> 
>> This document does not allow or prohibit any particular extended error
>> codes and information be matched with any particular RCODEs. Some
>> combinations of extended error codes and RCODEs may seem nonsensical
>> (such as resolver-specific extended error codes in responses from
>> authoritative servers), so systems interpreting the extended error
>> codes MUST NOT assume that a combination will make sense.
> 
> I think that works.  I extended it with one more sentence:
> 
>      <t>This document does not allow or prohibit any particular
>      extended error codes and information be matched with any
>      particular RCODEs. Some combinations of extended error codes and
>      RCODEs may seem nonsensical (such as resolver-specific extended
>      error codes in responses from authoritative servers), so systems
>      interpreting the extended error codes MUST NOT assume that a
>      combination will make sense.  Receives MUST be able to accept
>      EDE codes and text in all messages, including even those with a
>      NOERROR RCODE.</t>

Thanks. However, I still think this opens a lot of security holes if developers try to be "smart" by assuming that some EDEs only make sense with some RCODEs. If I'm in the rough, I'll be quiet.

--Paul Hoffman