it sounds to me that a discussion on assumptions with EDEs and RCODES would be useful in the security considerations section as well.
and Wes, it should be "Receivers MUST be" and not "Receives MUST be" in your last sentence. Tim On Tue, Sep 10, 2019 at 8:43 PM Paul Hoffman <paul.hoff...@icann.org> wrote: > On Sep 10, 2019, at 4:02 PM, Wes Hardaker <wjh...@hardakers.net> wrote: > > > > Paul Hoffman <paul.hoff...@icann.org> writes: > > > >> On Sep 9, 2019, at 9:05 PM, Wes Hardaker <wjh...@hardakers.net> wrote: > >>> > >>> Paul Hoffman <paul.hoff...@icann.org> 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 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
