Subject: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

From: tjw ietf <[email-masked]>
Date: Tue, 25 Jul 2017 12:04:04 -0400

This draft was the only one which seemed to have broad support in some form
during the meeting last week.

This starts a Call for Adoption for draft-wkumari-dnsop-extended-error

The draft is available here:
https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02

Please review this draft to see if you think it is suitable for adoption by
DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 8 August 2017, 23:59

Thanks,
tim wicinski
DNSOP co-chair

---

From: Bob Harold <[email-masked]>
Date: Tue, 25 Jul 2017 14:29:34 -0400

On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf <[email-masked]> wrote:

> This draft was the only one which seemed to have broad support in some
> form during the meeting last week.
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
This appears to be useful.  I will review and contribute.

-- 
Bob Harold

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 25 Jul 2017 16:21:17 -0300

I also support adoption. Current SERVFAIL messaging provides too little 
information for interested parties and makes debugging problems 
difficult.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Peter DeVries <[email-masked]>
Date: Tue, 25 Jul 2017 15:46:50 -0400

I have read the draft and support adoption.  I plan to review and
contribute.

Peter

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Jul 2017 09:01:06 +1000

read, support adoption.

suggest that favourite band sections be marked 'RFC-ED REMOVE' because
the last time somebody thanked their mother, the backing band, their
agent, the producers, the other candidates for award... it wound up on
the ietf list and we don't want to go there.

I am unsure about the R flag and proscriptive language. It seems to me
that it can't be a single bit flag and suggest BOTH retry, and retry
another NS. Also, the rest of the flag word is set zero. Surely thats
'...at this time'

And then the list of when to set, maybe set, maybe not set.. I think
thats still a bit up in the air.

But thats now WG matter to discuss I guess (assuming it got adopted)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 Jul 2017 10:11:13 +1000

In message <CAKr6gn1JnndzwyqoESM_Ap5=[email-masked]>, George Michaelson writ
> the ietf list and we don't want to go there.

It went to the IETF mailing list because it was added in AUTH48.
If I've read concensus of that discussion correctly there would
have been no issue if it was added earlier in the process.  The
problem was timing not content.

Too many times IETF members take procedual decisions out of context
and apply them elsewhere.  This is just one example of that.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Jul 2017 10:16:36 +1000

my next draft will definitely include "....I'd like to thank Mark
Andrews for hitting me with a cluestick repeatedly WAIT WAIT WHY IS
THE ORCHESTRA STARTING OH MANNNNN"

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 26 Jul 2017 11:36:10 +0200 (CEST)

I support the adoption.  Will make an effort to review if enforced with sharp object :)

O.
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "tjw ietf" <[email-masked]>
> To: "dnsop" <[email-masked]>
> Sent: Tuesday, 25 July, 2017 18:04:04
> Subject: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

> [ https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 |
> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 ]
>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jul 2017 15:12:59 +0000

On 7/25/17, 12:04, "DNSOP on behalf of tjw ietf" <[email-masked] on behalf of [email-masked]> wrote:

>This draft was the only one which seemed to have broad support in some form during the meeting last week.   

>https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02[tools.ietf.org]

>Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view.

>Please also indicate if you are willing to contribute text, review, etc.

It's funny that the older you get and the more you see the same old question the less clear what the right answer is.

I thought the intent of EDNS was to extend things like the response codes.  "Extension Mechanisms for DNS (EDNS(0))" [https://www.rfc-editor.org/std/std75.txt] includes "EDNS provides a mechanism to ... provid[e] extra data space for ... return codes (RCODEs)."  So entertaining a WG work item/draft on EDNS'ing RCODEs is a no-brainer, I mean, bring it on.

But the draft itself isn't exactly the way I'd go about solving the problem.  Does that mean it shouldn't be adopted?  I suppose not, I suppose the answer is to adopt it and change it mercilessly.

In a separate message, I'll send some comments about the draft.  I don't know if I'll be tuned in enough to follow up (I don't often take time to read the list like I used to do), so I won't promise anything beyond that.  It's a matter of time and priorities.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Jul 2017 12:46:24 -0700

Edward Lewis wrote:
>
> But the draft itself isn't exactly the way I'd go about solving the
problem. Does that mean it shouldn't be adopted? I suppose not, I
suppose the answer is to adopt it and change it mercilessly.

agreed.

-- 
P Vixie

---

From: Shane Kerr <[email-masked]>
Date: Thu, 27 Jul 2017 08:08:27 +0000

Tim,

At 2017-07-25 12:04:04 -0400

> during the meeting last week.

To be fair, I think that we could say that this was the only one having
complete support during the meeting. Several drafts had support with
only a few people whining because it didn't help their own
operations. ;)

> This call for adoption ends: 8 August 2017, 23:59

I support the draft, and am willing to contribute text and review!

I have a few points now, in fact:

1. Does it make sense to divide the response codes up into those
   corresponding to each error type? That is, something like 1xxxx for
   SERVFAIL, 2xxxx for FORMERR, and so on?

2. Do we mind having lots of error codes? For example, we can go really
   far and do things likes DNSERR_BADCOMPRESS "name compression used
   in RRTYPE that forbids it", or DNSERR_NAMETOOLONG "name longer than
   255 bytes", and so on. We could end up with hundreds of error codes.
   As a developer I don't mind this too much, as these provide hints
   about stuff you should be considering, but I can see why some people
   would prefer to keep it simple.

3. As a concrete proposal, I suggest DNSERR_CENSORED, with the code 451
   for consistency with the HTTP response code. This may be a useful
   addition to the RPZ draft. ;)

Cheers,

--
Shane

---

From: Roy Arends <[email-masked]>
Date: Thu, 27 Jul 2017 11:34:20 +0100

> On 27 Jul 2017, at 09:08, Shane Kerr <[email-masked]> wrote:
> 

Loving this idea. 3xxxx for REFUSED.

>   would prefer to keep it simple.

Really like this as well. I think it is really helpful.
>   addition to the RPZ draft. ;)

Sure.

Roy

---

From: Petr Špaček <[email-masked]>
Date: Thu, 27 Jul 2017 17:54:56 +0200

> suppose the answer is to adopt it and change it mercilessly.

I agree. The draft needs more thought and work on text but in general it
is very useful concept. I will be happy to review it and propose changes.

-- 
Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Jul 2017 10:54:47 +1000

> >   addition to the RPZ draft. ;)

Well if we want to add new error code we need to bump the EDNS
version field or otherwise indicate that the client supports new
error codes.

NXRRSET instead of NOERROR with NODATA
NOTAUTH instead of REFUSED when not configured to
	serve the query's namespace.  We already do this for AXFR / IXFR.

If we want to reattempt to add new labels types a more precise error
code would be useful.  In this case the use of the new label type
would be a signal that the error code (and EDNS) is understood.
Query minimisation is also required to achieve this as then only
the servers for zones with such labels need to support the label
type.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 28 Jul 2017 18:09:32 -0700

At Tue, 25 Jul 2017 12:04:04 -0400,

> DNSOP, and comments to the list, clearly stating your view.

I support the adoption of the draft, if only to provide a way of
signalling more helpful DNSSEC-related errors than a plain SERVFAIL.
I may or may not support the specific proposal for that goal in the
end, though (I simply don't know at this moment).

I've reviewed draft-wkumari-dnsop-extended-error-02 and am willing to
review followup versions.

My comments on 02:

- I wonder what if a forwarding recursive server receives a response
  containing an extended error (especially from an upstream validating
  resolver sending an error regarding DNSSEC validation).  Is it
  expected to forward it back to the downstream client?

- Can more than one extended error code be included in a single
  message?

- One possible idea of another extended error code: one that indicates
  a type-ANY query is responded with just one type of RRset when there
  can be more.  Technically it may not be considered to be an "error",
  but at least it indicates some special condition, so I think it's
  worth discussing.  (This may also be related to question 1 of
  Section 6).

- Section 1

Editorial

- Section 1

   When a
   stub resolver queries a DNSSEC bogus name (using a validating
   resolver), the stub resolver receives only a SERVFAIL in response.
   [...]

  If this is a major motivation of this proposal, it may not be very
  effective depending on how modern the stub resolver is.  I suspect
  many existing stub resolver implementations still don't even include
  EDNS(0) in their queries (at least by default).  It doesn't
  necessarily mean this proposal is completely useless, but we may
  have to note it won't be as effective until and unless the majority
  of stub resolvers become more modern.

- Section 2

   o  FLAGS, 2 octets.

  We might just define the R bit and keep the remaining 15 bits
  "reserved", unless we know we'll definitely use these as "flags".

Editorial nits:

- Section 1

   - e.g the answer was marked REFUSED because of a lame delegation, or
   because there is a lame delegation or because the nameserver is still

  "or because there is a lame delegation" is redundant and should be
  removed?

- Section 7

   and do don't get any of the protections which DNSSEC should provide.

  s/do don't/don't/

--
JINMEI, Tatuya

---

From: Paul Wouters <[email-masked]>
Date: Sat, 29 Jul 2017 08:53:48 -0400 (EDT)

> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error

I have reviewed the draft, and while I think it could be useful, I'm
seriously worried about sending unauthenticated errors back to the user,
and fear that software will start using these without first validating
the response using DNSSEC.

I would like to see more discussion on this topic before adopting this
document with a focus on how we could secure these error codes.

Paul

---

From: Shane Kerr <[email-masked]>
Date: Sat, 29 Jul 2017 15:05:42 +0200

I guess that I understand your concern, but we don't have any way to authenticate servers in DNS today and we already send error messages back. 

I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Tony Finch <[email-masked]>
Date: Sat, 29 Jul 2017 14:27:57 +0100

神明達哉 <[email-masked]> wrote:
>   can be more.

Note that it is almost always the case that ANY answers from
non-authoritative servers are a subset of the records :-)

And it seems difficult for a cache to determine when to use this extended
error code. If the cache was populated by an A query (say) it can't know
if this is a subset of the owner's records or not; if it populated the
cache from an ANY query then the records can expire at different times, so
it would have to keep track of this to know if the extended error becomes
relevant.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Northeasterly 5 or 6, increasing 7 or gale 8 at first in
west. Moderate. Rain or showers. Moderate or good, occasionally poor.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 29 Jul 2017 15:19:35 +0200

+1 (in favor)

[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Sat, 29 Jul 2017 10:04:06 -0400

Hi Shane,

> I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? 

In the case of validation failures, today a DNS client (of whatever kind) can receive a SERVFAIL of unknown authenticity from a resolver and has to do more work to figure out what that means. It can't just assume that there has been a validation failure upstream. Ultimately it can re-fetch records with CD=1 and do its own validation if it needs to understand the reason for the failure in detail.

The motivation for extended RCODEs is to be able to provide more fine-grained indiciations to a client than are currently provided. In the case of a conventional SERVFAIL response, for example, the client might also receive some information that further indicates that the reason for the SERVFAIL was an upstream validation failure.

It feels like there is more potential in this second case for a client to believe what it was told and avoid further checking (this is an example of your "change client behaviour"). Without an authenticated response, should we not be concerned about the threat that a bogus response from a third party system might mask an otherwise legitimate and positive response? If client behaviour is not supposed to change when you return an extended RCODE, why bother returning one?

I'm not saying this particular threat is credible or high-probability necessarily, but it seems sensible to think about this with a little more energy than "it's no worse than what we have today". Maybe the answer is to say "don't use this mechanism to indicate validation failures". Maybe there's a different approach that could accommodate signed extended responses, and writing that up from scratch is more sensible than adapting what's currently on the table. I'm not presupposing the answer, just thinking aloud.

I don't have a strong opinion about it, but it does seem reasonable to consider these kinds of things before assuming that any particular draft fits the requirements and should be adopted.

Nothing against Warren's fine draftsmanship, of course!

Joe

---

From: Evan Hunt <[email-masked]>
Date: Sun, 30 Jul 2017 07:42:54 +0000

On Sat, Jul 29, 2017 at 10:04:06AM -0400, Joe Abley wrote:
> If client behaviour is not supposed to change when you return
> an extended RCODE, why bother returning one?

It's clearly helpful for human debugging.

But, yes, you're correct -- diagnostic information included with a
SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
authentication mechanism such as TSIG, clients should not rely on it or
base policy on it.

Some of the error codes might be trustworthy enough if you're using COOKIE
or TCP; that would enusre at least that it wasn't an off-path forgery. The
ones related to validation I wouldn't trust without a signature, though.

This should be spelled out in more detail in the security considerations.
(And, considering I'm listed as a co-author on this draft, maybe it's time
I earn my keep and submit some text...)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jul 2017 15:22:23 +0200

>  authentication mechanism such as TSIG, clients should not rely on it or

=> TSIG can be in a response only if the query is signed...

Regards

PS: I remember a similar operation vs security trade-off about IKEv2 NOTIFY
messages: in some cases it is better to get unsecure information than
no information at all because security is required. BTW in the case
of this proposal it is second order because the real/main error is
the SERVFAIL (or others but after a short study of bind9 code the first
time this idea was proposed it should be at 90% or more SERVFAILs).

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jul 2017 09:57:11 -0400 (EDT)

> authentication mechanism such as TSIG, clients should not rely on it or

But we know people are already building software and systems that DO
trust the AD bit, even with non-localhost resolv.conf entries. This
saves them the overhead of adding a dnssec library to their application,
and saves them from running a system resolving understanding dnssec.

So I'm pretty worried that people will treat new unprotected error
codes exactly the same. They'll handwave and say that's the system
administrator's issue to solve, not the application's responsibility.

> or TCP; that would enusre at least that it wasn't an off-path forgery.

That's a very small use case with pervasive monitoring and
coffeeshop and hotel wifi.

> This should be spelled out in more detail in the security considerations.

I'm seriously afraid that's not going to matter at all when people
implement this.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Mon, 31 Jul 2017 17:11:07 +0000

> and saves them from running a system resolving understanding dnssec.

Are there applications specifically trusting AD=1 and behaving differently
than with AD=0?  Or are they just ignoring it and trusting every answer
equally?  I would have expected the latter, but I confess to being
surprised if there are people going out of their way to implement "DNSSEC
validation" by just buying whatever magic beans some dude in the forest
has for sale.

> coffeeshop and hotel wifi.

In case I wasn't clear, I'm suggesting that TCP and COOKIE would be
adequate protection for any error code where the worst case scenario is
no worse than what any MITM can do. If you've already got control of the
channel, then I can't see how sending the client "Prohibited" or "Lame"
messages gives you any more of an advantage than you already had.  However,
any response that says anything about DNSSEC validity should be presumed
guilty until proven innocent.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 31 Jul 2017 14:16:37 -0400

Postfix is one but last I knew only when resolv contains localhost.

I think systemd-resolved also does various tricks but haven't looked at that in a long time.

Software doesn't want to link against a dnssec library. Hopefully we can get something smaller and better if we can use query-chains (via stubby, TLS, etc) that removes most of the DNS code from getting and processing a dnssec chain.

Paul

Sent from my iPhone

> On Jul 31, 2017, at 13:11, Evan Hunt <[email-masked]> wrote:
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 31 Jul 2017 20:13:11 +0000

> Postfix is one but last I knew only when resolv contains localhost.

Not only Postfix, also Exim, and perhaps also Sendmail some day
if/when DANE support appears there, partial support is already
in the snapshot code:

    ftp://ftp.sendmail.org/pub/sendmail/snapshots/sendmail.8.16.0.21.tar.gz

That code also relies on the (presumably configured local) resolver's
AD bit.  In all three code bases making sure that the resolver is
actually local is up to the MTA administrator.

I expect this implementation strategy will be near universal.

> Software doesn't want to link against a dnssec library.

Correct.  Software similarly also does not want to explicitly add
code to handle Kerberos, ... which is why various indirect approaches
are becoming popular for handling security "out of process".  Having
a local resolver with a trustworthy "AD" bit is a feature, not a
bug.  

The AD bit is exactly the right DNSSEC interface.  All that's
missing from the traditional libresolv (and not missing from recent
innovations in res_ninit(), res_nsearch(), ...) is the ability to
specify the loopback address as the sole resolver in the application.

No matter how much some here might want to discourage the "AD" bit
interface, it is the main one that developers will use, if they
use DNSSEC security signalling at all.  So it is up to the platform
vendors to improve security by delivering systems with a default-on
local validating resolver (that forwards to any upstream servers
that would otherwise have been used directly).  This also improves
latency by bringing the cache closer to the application.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 31 Jul 2017 20:51:21 +0000

> document with a focus on how we could secure these error codes.

My DANE-related code always treats SERVFAIL as insecure, a more
detailed SERVFAIL would still be insecure.  I don't see any new
exposure here.  Providing additional diagnostic information can
help with deployment.  Eliding useful information because some fool
might misuse it is IMHO the wrong trade-off.

Where necessary, the final document can emphasize that the information
provided, is typically useful, but is not trustworthy.  The intended
purpose is presumably to facilitate problem resolution by enabling
clients to report more detailed diagnostics to the server operator.

Logging something more useful than SERVFAIL (e.g. signature
expiration, lame delegation, ...) would be quite useful.

Sometimes, by the time a problem is noticed in the logs it is no
longer observable in real-time.  Having a better record of what
happened at the time of the problem is valuable.

-- 
	Viktor.