[DNSOP] EDNS checksumming (was EDNS reply option to list unsupported options from query)

[Shane Kerr <[e-mail]>]

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
Paul Vixie <[e-mail]> wrote:

> Paul Hoffman wrote:
> > 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?
> 
> well, that was my reasoning for not including end to end checksumming in
> 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