Re: [dns-privacy] [SPAM] Re: New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

[Carsten Strotmann <[e-mail]>]

Hello Hosnieh,

Hosnieh Rafiee writes:

> I change my story a bit based on some offlist discussions ...
>
> So the point 1 from summary email changes like this
> 1-  Opportunistic encryption is not appropriate for the privacy of stub
> resolver to recursive resolver scenario unless the node has a possibility to
> authenticate this resolver.
> If you think when your domain is signed by DNSSEC, a fake resolver cannot
> cause any problem for you, I gives you an example. You can argue with your
> own example.
>
> This is the scenario where there is no authentication but a  record is
> supposed to signed by a DNSSEC server. 
> A domain called www.example.com signed by DNSSEC A.  
> Client B wants to browse "www.example.com". 
> It asks the IP address of this from resolver C. Attacker D spoof the IP
> address of resolver C and response to this query with the IP address of his
> own server F. The client cannot verify this attacker in any case since it is
> only a stub resolver and dependent to a recursive resolver for query
> different authoritative DNS server in order to verify this DNSSEC server.
> This is why the stub resolver accepts whatever receives from this fake
> DNSSEC server. 
>
> So, either client B encrypt the queries send back and forth to the resolver,
> it ends to the case where the unwanted person can still eavesdrop this
> communication by directly answer to the node in place of resolver.
>
> In my opinion it does not matter whether this record is signed or encrypted,
> the stub resolver has no possibility to verify that record. So, an attacker
> can directly be in the middle of the communication and forward all the
> packets to his desire place. So DNSSEC in this stage or last mile does not
> help. 
>
>
>> > How can you sign DNSSEC data without being in the posession of the
>> > private signing key(s) all the way to the root?
>
> So based on the revision in item 1. I can also revise my answer here.
>
> I don't need to sign the DNSSEC data since the stub resolver is dependent to
> me (or a DNSSEC recursive resolver) to verify any other DNSSEC server. 
>

As the draft mentioned the stub-resolver cannot rely on the DNSSEC
validation of an un-authenticated, unknown DNS resolver. 

Either the stub-resolver, or the application, needs to do the DNSSEC
validation. While not widely deployed, this is possible today. 

For this local validation, the stub-resolver or the application has one
or more DNSSEC "well-known" trust-anchors (like the DNS root zone trust
anchor, or the ".de" zone trust anchor) pre-configured. The validation
does not rely on the any data received via the unautenticated DNS
resolver. The integrety of DNSSEC signed DNS zone data can always be
checked.

A malicious unauthenticated and unknown DNS resolver can stop all
communication by providing false DNS data, but the false data is always
detected.

DNSSEC validation does not rely on the the data received through the DNS
resolver, which might be malicious. The trust anchor is configured
before this communication, out-of-band, coming with the software or
manually configured.

-- Carsten
-- 
Sent with my mu4e