On Tue, 19 Aug 2014, Hosnieh Rafiee wrote:
Data integrity is different than authentication. I am not talking about data
integrity. If you can verify the data integrity of a node, it doesn't mean that
it is authenticated. DNSSEC, at the moment is unable at the moment to protect
his last mile and your draft is supposed to provide this protection but at the
moment it does not.
That's not how I read the draft. The last mile protection needed is
privacy, not integrity. I believe every node on the planet needs to
validate or have a trusted path to a validator. But that's all unrelated
to this draft. This drafts is about encrypting (and maybe possible
authenticating) the last mile. Protection against passive attackers,
(and maybe protection against active attackers)
2- encryption
If I'm at starbucks, I care more about encrypting the last mile then
authenticating the random starbucks location. And even if I
authenticated the starbucks, they will just use an ISP DNS server that
sees all the queries, so that local authentication does not really help
you much anyway.
Doesn't make sense... Your data is now all go through attacker, it doesn't
matter for you? Then what privacy is supposed to be provided to the user?
Most attackers at the starbucks can only monitor what I send and receive,
and do not actively send attacking packets to me.
DNSSEC allows us to ask DNS data from random attackers, as we will be
able to verify the authenticity of data. I do not need to authenticate
the resolver for that.
This is wrong. Then why do you bother yourself to encrypt the resolver.
To prevent wifi monitors from reading my DNS queries and answers.
When you do not authenticate your resolver, what is important that some people
do not see what you are browsing?
That's my call to make, not yours.
I disagree with you and I think authentication and encryption together make
sense. Even authentication alone is securer than encryption alone.
I have authentication of data via DNSSEC already. And I did not say it
makes no sense to authenticate the local resolver. If you can, great and
do it (and the draft says do it via some out-of-band method). But how on
earth am I going to authenticate joe random coffeeshop from joe random
attacker???
So this is all about encryption. We might want to authenticate with the
network to encrypt with the good guy and not the bad guy. But if you're
in a random untrusted network, you are going with an unknown guy anyway,
so authentication matters much less.
The question is what you are encrypting? Some domain names? Are they as
important as you really need to do so?
Again, that is my call to make, not yours. There is a difference between
the network owner/manager and the dozens of guests on the network. I
trust one more than the other.
It is not the question of untrusted network, it is about pervasive monitoring.
The good guy can be a network administrator or a government?!! who also
interested to receive information passed through this network. He can easily
play MITM attack since you trust this resolver in any case.
And so can they when you authenticate the starbucks wifi, who then does
a backhaul to their DSL provider's DNS server. So I fail to see what
authentication of the local DNS server with authenticated encryption
on the local wifi, helps me from nation state monitoring? That's not
really what this draft is trying to do. If you need that, you need the
tor network for DNS as a starting point....
When you cannot authenticate a node, any node in even a good network can play
this MITM attack. One example, you want to hide what you are browsing from your
colleague... well, that is easy, your colleague will introduce his computer as
a resolver and play MITM attack. Then who are you hiding the domain name or
whatever stored in DNS resolver from?
Yes, you made this point a few times now. And I answered with explaining
passive versus active attacks.
IMHO both authentication and encryption are the requirements for resolver
privacy.
As I explained, authentication of joe random resolver is pretty
pointless. I'm at the mercy of the DHCP server, for which there is
no authentication whatsoever anyway.
DNSSEC cannot do anything when your node doesn't know who is it connecting
to... when you cannot verify the source of your message, data authenticity and
encryption is not really useful. In any case, DNSSEC cannot help you in this
scenario.
DNSSEC allows me to use unknown or untrusted resolvers. While I am not
sure of my privacy, I'm pretty sure about my data integrity.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
