Re: [DNSOP] SIG(0) useful (and used?)

[Shumon Huque <[e-mail]>]

On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <[e-mail]> wrote:

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <[e-mail]>
> wrote:
>
> On 06/20/2018 04:59 PM, Tom Pusateri wrote:
>
> DNSSEC will tell you the answer you get is correct but it could be a > to
> a different question or be incomplete.
>
> Can you elaborate on that point.  I believe in signed zones you are able
> to verify almost everything, in particular existence of the queried-for
> RRset and its exact value, except for details like current TTL.
>
> --Vladimir
>
>
> I’ve been thinking about the case when you are given a DNS recursive
> resolver over DHCP and you don’t necessarily trust it.
>

SIG(0) can't really protect you from an untrustworthy resolver. It can
ensure that the question you sent and the answer you got back from the
recursive server was not tampered with in-flight. But it can't detect
whether the recursive server modified any data in its response before it
signed it with SIG(0). If the response contained DNSSEC signed data and the
stub was validating, then those pieces of the response could be
authenticated. But not anything in the header, question etc - all of that
could have been modified by the recursive server without detection.


> If you send a query with the DO bit set to a recursive resolver for the A
> record for foo.example.com and the recursive resolver modifies this query
> to foo.exampl.com, you can get back a validated DNSSEC response with the
> A record answer, RRSIG, NSEC(3) records all for the wrong question. The
> resolver code in the OS or application would get back the matching DNS
> header identifier and if it lazily just grabbed the A record answer without
> comparing the RR name, it could be misled. You can detect this without
> SIG(0) so maybe that was a bad example. But if you always sent a SIG(0)
> signed question and got a signed answer, you could detect this and possibly
> other future attacks and drop it before even parsing the answers.
>

Most competent resolvers will check that the response that they got back
was for the question they asked. So I don't think they would "lazily just
grab the A record answer without comparing the RR name".

I don't think SIG(0) really helps much here. The response signature has to
include the entire query message, but the actual response can contain
anything the recursive server puts in there.


> In the case of missing answers, I was thinking that if there were multiple
> A records in the response and some were filtered, you could not detect this
> without a SIG(0) signed response from the authoritative server. This would
> be important if one server was compromised and the recursive resolver
> filtered the response to exclude the other A records pointing to servers
> that weren’t compromised directing you to the compromised server.
>

DNSSEC is really the solution to this problem. DNSSEC signatures cover the
entire RRset, so authoritative (or recursive) servers cannot strip away
some of the RRs without detection by a downstream validator.

Shumon.