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

Why would that make a difference?

On Thu, Jun 21, 2018 at 3:34 PM Tom Pusateri <pusateri@bangj.com> wrote:

>
>
> On Jun 21, 2018, at 1:40 PM, Shumon Huque <shuque@gmail.com> wrote:
>
> On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <pusateri@bangj.com> wrote:
>
>> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
>> 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.
>
>
> Thanks. In the case where a zone isn’t signed but the authoritative server
> supports SIG(0), the response could be verified that it includes exactly
> what the server sent. But the KEY would need to be DNSSEC validated or it
> probably can’t be trusted to verify the SIG(0) response.
>
> Tom
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>