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]>]

Hi Carsten,

Thanks again for your response.
The problem about this draft is that, they did not consider authentication
as a necessary step and only presumed that some other services would do this
task for them and they only focused on encryption. All the discussion back
and forth is because I think the focus should be on both and encryption
alone let the observer to retrieve and watch the data.  In other words, for
instance if a service implement such draft, it fails if they do not change
their focus on both. 

What I understand from privacy is that we want to disallow an observer to
watch our data. This observer is usually inside our own network or somewhere
in our network where our first point of this communication is also a
resolver that we might not be able to trust because it is not clear it is a
trusted resolver or a fake one. So when an observer can easily change his
role to one of this fake resolver and watch data. Encryption ends to him. 


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

This is why I said there is missing part in this draft. "cannot" is
different than offering a certain solution. 

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

I think this not the task of stub-resolver. If stub resolver supposed to
play a role of recursive resolver and query different authoritative DNSSEC
servers from "." to "www.example.com" , then it is not called a stub
resolver and it is recursive resolver.  So then the question is what is the
task of recursive resolver? Is there any plan to change all stub resolver in
future to recursive resolver and remove the recursive resolvers on internet?

If purpose is to give these tasks to other services then I think it needs to
be mentioned clearly in the draft that "HOW" this can be done. This is all
what effect on privacy consideration of the draft and , of course, the
implementation of this draft and important because again encryption alone
does not make sense either they use opportunistic encryption or be lucky and
use  a fixed encryption approach. (people think I am against opportunistic
encryption but this is different, I am against encryption without secure
authentication) So that, all implements this approach and always encrypt the
packets. As far as the observer has the easy opportunity to forge the
identity of a resolver, encryption is like boiling the ocean water. 

The problem is that , often, like the example of wifi connection, the node
is anonymous. Do you plan to preconfigured all nodes inside a network with
the preconfigured value of some trusted anchors? This is especially really
difficult when the nodes in a network are dynamic like a wifi connection. 

I guess the problem here is not well defined... in my opinion the problems
that a draft needs to address for privacy consideration are as followings:

- secure robust authentication (essential)
- encryption (good to have)
- automation to whatever extend possible (essential)
And of course performance (good to have)


Maybe if you install an active directory, you solve all this problems but
you cannot trust all nodes in a public network to join to your domain that
they can access to the list of trusted anchors and can automate this task to
some extend. 
If this was an easy task or feasible task,  there wasn't always a discussion
about DNSSEC and last mile of Internet.... 
 

> 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.

Not stub resolver but the recursive resolvers usually preconfigured with
what you say. But the problem here is real task of stub resolvers and what
they are expected to do. 

And the application here in my opinion is out of scope otherwise they plan
to say this draft is very dependent to x application to do this
authentication and without this, the implementation of such approach is not
really helpful because the observer has a chance to easily forge the
identity of the resolvers.

> 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.

This actually not the question of what DNSSEC can do . But here is the
question of how to solve privacy problem (if the plan is to also use DNSSEC
as a part then the question is what DNSSEC cannot do and what the drafts
should address to assist what it cannot do.) 


Thanks,
Best,
Hosnieh