Subject: [DNSOP] EDNS reply option to list unsupported options from query

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Sep 2015 22:33:42 +0530

Hi everyone

RFC6891 says this:

>   Any OPTION-CODE values not understood by a responder or requestor
>   MUST be ignored.  Specifications of such options might wish to
>   include some kind of signaled acknowledgement.  For example, an
>   option specification might say that if a responder sees and supports
>   option XYZ, it MUST include option XYZ in its response.

There is no generic way for a client to know that an option was not
handled at the server side. This is sometimes a problem when introducing
new options - while option specifications typically implement some sort
of reply signalling, it's not always the case where the client can know
with a missing option if it was not included because of lack of support,
or due to some other cause.

Is it worth introducing a reply EDNS option whose OPTION-DATA contains a
list of all the 16-bit OPTION-CODEs that were ignored from the query
message, and make it a MUST requirement?

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2015 10:11:56 -0700

Mukund Sivaraman wrote:
> handled at the server side.

wait, what? the text you quoted is clear on that topic.

> ...

no.

-- 
Paul Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Sep 2015 22:44:52 +0530

> > message, and make it a MUST requirement?

:-)

		Mukund

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Sep 2015 10:19:20 -0700

Paul's "no" (which I agree with) shows what might be a fatal flaw in 
draft-muks-dnsop-dns-message-checksums: an attacker just needs to send 
fragments that look like they say "I don't understand the new EDNS0 
option". Does that make sense?

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2015 10:21:54 -0700

> option". Does that make sense?

well, that was my reasoning for not including end to end checksumming in
EDNS0 itself (as a fixed field.)

-- 
Paul Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Sep 2015 23:01:13 +0530

Hi Paul

> Paul's "no" (which I agree with) shows what might be a fatal flaw in

Even if Paul had said "yes", this security consideration still exists
(see below). The reason why I sent the EDNS option handling email was
because it sometimes is not apparent with newer options if it was left
out because there was no support, or because of some other condition.

> fragments that look like they say "I don't understand the new EDNS0 option".
> Does that make sense?

I really appreciate the sharp review. This was also pointed out by Ray
Bellis during internal review. It is listed in the github repo under
security considerations. The latest version of this draft in text form
is here:

http://users.isc.org/~muks/draft-muks-dnsop-dns-message-checksums.txt

As with any new protocol, if the protocol is not supported on both ends,
nothing can be done for it. The SHOULDs turn to MUSTs at some point when
support is widespread. Currently it's the client's choice on what action
to take if the option is missing from a reply.

		Mukund

---

From: Shane Kerr <[email-masked]>
Date: Tue, 29 Sep 2015 12:02:19 +0000

Paul(s) & all,

tl;dr a checksum adds some small benefit for a moderate cost... worth
      it?

On Mon, 28 Sep 2015 10:21:54 -0700

> EDNS0 itself (as a fixed field.)

A resolver can remember which authority servers support the checksum,
providing a small measure of protection against downgrade attacks.
(This would have also been the case with a nonce in ENDS0, which
Michael Graff said that he pushed for but failed.) Certainly not
perfect, but also not completely worthless.

In the case of fragmentation for normal DNS queries, an attacker can
bypass having to guess the 16 bits of entropy in the query ID, because
the fragments do not carry this information. (There were presentations
on this a couple years ago, IIRC.)

If a checksum is added it will probably show up in the final fragment.
An attacker now needs to insure that the final fragment shows up before
the final fragment from the real authority server. This is not too
difficult, since the attacker is already preparing an attack that
depends on fragments arriving before the non-spoofed fragments....
unless the resolver has an indication that an authority server supports
checksumming.

All of this implies some moderate complexity for resolvers to handle
the logic properly. I'm guessing BIND 9 would implement it if
standardized, so maybe it is worth it?

Of course, the real answer is "use TCP". :)

Cheers,

--
Shane

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 Sep 2015 17:57:11 +0530

Hi Shane

> unless the resolver has an indication that an authority server supports

As you have pointed out, there is currently no way to gather this
reliably. One can only deal with it by implementing the option as
"SHOULD-return-a-checksum" for now, wait for implementations to pick up,
and then make it a "MUST-return-a-checksum-or-use-TCP" some day in the
near future.

If this was implemented in EDNS from day 1, EDNS support would have
implied checksums. Of course, it's possible to break this too, but the
client has to make the choice of throwing it away and using TCP then.

		Mukund