Subject: Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error

From: Petr Špaček <[email-masked]>
Date: Fri, 8 Nov 2019 15:33:28 +0100

On 31. 10. 19 20:08, Eric Orth wrote:
> On Fri, Oct 25, 2019 at 9:29 AM Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Would it be possible to get some time allocation of your UX design folks, before we set the protocol in stone?
> 
> 
> Not likely, unfortunately.  Downside of not having specific plans yet.  Makes it difficult to allocate UX experts.
> 
>     - Is the current version with "no categorization" okay?
>     - Will it be okay in future if dnsop starts adding new codes?
>     - Or should we add some inherent categorization into the protocol to make it future-proof?
>     - If a categorization is needed, what form is best for UX? (please suggest!)
> 
> 
> Speaking for myself from a non-UX perspective (and I am not a UX expert), forward compatibility of error codes is a common pitfall in many similar systems.  Once error receivers start relying on specific error codes to produce specific essential behavior, expandability often gets locked out because you can't replace those codes with new ones that receivers might not immediately recognize.  And having a receiver only know "unknown" error is usually pretty bad.  Attempts to solve these issues usually involve stuff like categorization, user-visible messages, and multiple ordered errors, but my anecdotal experience is that it's pretty rare for such mitigations to be fully supported by all sides to the level where it actually helps and expandability still ends up limited.
> 
> But specifically to EDE, I think the general circumstances make us fine without taking any specific steps to mitigate forward compatibility.  It's mostly been designed just for "supplemental" signalling.  And at least for the general use cases, eg browsers, I doubt enough recursives will ever (or be able to) support it for the stub to rely on receiving a recognized EDE.  It will always need to be a nice-to-have with the receiver able to provide good behavior if no EDE (or an unrecognized new EDE) is received.
> 
> So no, I don't think categorization is necessary to make EDE useful.  In fact, I think it would probably make things more complicated than necessary.

Thanks!

Based on this feedback I'm dropping my former request to build categorization into the protocol, so the "flags" field can rest in peace.

Thanks everyone for patience with me. Let's move to the forwarding question! :-)

-- 
Petr Špaček  @  CZ.NIC

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Nov 2019 09:53:49 -0800

"Jan Komissar (jkomissa)" <[email-masked]> writes:
> In section 2, Extended DNS Error EDNS0 option format, it states that
> the OPTION-LENGTH should be “4 + the length of the EXTRA-TEXT section…
> .” This appears to be a remnant from when the option included a flag
> word. I think it should be changed to “2 + the length of the
> EXTRA-TEXT field… .” I also changed “EXTRA-TEXT section” to
> “EXTRA-TEXT field,” since the draft call these items “fields.”

Thanks.  Fixed!
-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Nov 2019 09:56:20 -0800

Puneet Sood <[email-masked]> writes:

> Independent of the decision on EDE forwarding and caching, the I-D
> needs to have some guidance for it [truncation]. The EXTRA-TEXT field
> may be obtained from configuration and it is possible that the
> resulting DNS message will exceed UDP message size limit in the
> request.

I added this text to the next version:

      <t>When the response grows beyond the requestor's UDP payload
      size <xref target="RFC6891" />, servers SHOULD truncate messages
      by dropping EDE options before dropping other data from
      packets.  Implementations SHOULD set the truncation bit when
      dropping EDE options.</t>

(and we'll have a forwarding discussion in Singapore)

> > * 14.5.0.4 NOCHANGE 5. Security Considerations
> >
> >   Para 2: "This information is unauthenticated information, and an
> >      attacker (e.g a MITM or malicious recursive server) could insert an
> >      extended error response into already untrusted data ..."  Comment:
> >      Agree with some other comments that this is not relevant since no
> >      action is expected to be taken based on EDEs.  Comment: There are
> >      ideas in the thread to have links to info in the EXTRA-TEXT and
> >      possibly display it to users. I guess the usual warnings to not
> >      click on potentially unsafe links apply.
> >
> >   + Yeah, it really would be remiss to leave out that point.  There may
> >     be nothing we can do, but the whole point of a security
> >     consideration is to properly disclose any known threats/issues.
>
> I do not see text mentioning this.

I think we're miscommunicating.  Can you propose concrete text changes?
-- 
Wes Hardaker
USC/ISI

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Nov 2019 15:55:10 -0500

> On Nov 13, 2019, at 12:56 PM, Wes Hardaker <[email-masked]> wrote:
> 

Are you sure that setting TC=1 when EDE doesn't fit is the right
trade-off?  I'm somewhat skeptical...

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Nov 2019 14:50:55 -0800

> trade-off?  I'm somewhat skeptical...

Well, that's what the other specs say.  We could break from that, you're
right, and it's a discussion I was going to mention in Singapore for
that matter.
-- 
Wes Hardaker
USC/ISI

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 Nov 2019 18:05:47 -0500

> On Nov 13, 2019, at 5:50 PM, Wes Hardaker <[email-masked]> wrote:
> 

A colleague suggested that would could use another bit (from the EDNS
flags field, say bit 14 adjacent to DO) to signal that non-essential
diagnostic information was left out.  Resolvers can then choose to
retry over TCP only if they deem it important to retrieve and use
EDE information.

It'd be a shame (though admittedly not frequent) to have a resolver
retry over TCP just to get the same answer with additional information
it does not need and perhaps does not even understand.

Of course this only matters in the rare (when not specifically elicited
by carefully crafted queries) case that it is the EDE options that push
the packet over the UDP size limit, and the rest of the payload would
otherwise just fit.  Perhaps on that basis the extra bit is not warranted.
We could just say that EDE can be silently dropped, or could leave the
text as proposed, with EDE occasionally eliciting "avoidable" TCP retries.

-- 
	Viktor.

---

From: Richard Gibson <[email-masked]>
Date: Thu, 14 Nov 2019 10:53:55 -0500

I like this idea, and am aware of at least two other proposals that 
would (or would have) benefited from a new OPT record [EDNS header flag 
bit] to communicate "incomplete response" as distinct from "truncated 
response" (the latter encouraging retry over a transport supporting 
larger messages, the former merely indicating that other data _could_ 
have appeared without encouraging a retry).

  * for refuse-any, indicating the existence of records not included in
    a response to a QTYPE=ANY query:
    https://mailarchive.ietf.org/arch/msg/dnsop/dfYqw2nUQqlcC2V6y34xKCtSE8Y
  * for multiple-responses, indicating the existence of records that the
    server could have included with better authentication or a different
    transport:
    https://mailarchive.ietf.org/arch/msg/dnsop/TmAWzUWUiHI2k1LXmx7rTzQD9lc

[EDNS header flag bit]: 
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 18 Nov 2019 11:59:13 +0100

> it does not need and perhaps does not even understand.

EDE codes themselves take very little space, so truncating just the
textual messages might be a good middle-ground.... but I certainly
haven't tried thinking of all implications on EDE truncation yet. 
Communicating these through bit(s) in EDE or EDNS flags might be nice,
and clients might even use them to set their preference.

Still, ATM I can't clearly see whether such TC details would be useful
in practice.  I think we're fortunate that most use cases for EDE are
failures... so the answer will probably be tiny.

--Vladimir