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

["Hosnieh Rafiee" <[e-mail]>]

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. 


Best,
Hosnieh