> > > Still the nodes are in processing the hello client exchange and the > encryption was not happened. As you explained in your draft, > opportunistic security is in use. In other words, the server might not > have certificate that is signed by a CA. In this case how the client > or server react when an attacker intercept this communication and > change "dns" to something else? > > encryption might happen without authentication.
But this fails... Because of the reason that I explained in my last message...Because your connection can be directly to the attacker's resolver and then you redirected to his own places or all the other communication would be through that attacker. So , the question is now does it matter that whether you encrypt this communication since you already have a MITM in your communication? Is it really important now? IMHO , NO... This is why I said it is different than sending an email because if your email goes through third parties only that third party have access to that certain message but not all the data exchanged after that with that certain server. The likelihood is not high. But when we are talking about a resolver, all your next communication will be influenced by this attacker because whatever place you go, it doesn't matter that you encrypt this data but it is through this attacker. > > Now the question is that if an attacker has an opportunity to change > this ALPN, what will happen? > > encryption without authentication is not enough to defend against > active attacks. If possible, use authenticated encryption. > > Note that DNSSEC provides authenticity of DNS data. So the only part of > authentication that you gain is about privacy (encryption) of data, not > about data integrity. 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. > > I think there is something important missing in your draft. For > > resolver's scenario IMHO, there is two important cases that the first > > one has a prioriry over the second one (this is of course my opinion > > and might not be the same as others) > > 1- authentication > > > > 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? > > I think authentication for a resolver is essential and more important > than encryption. > > 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. When you do not authenticate your resolver, what is important that some people do not see what you are browsing? I disagree with you and I think authentication and encryption together make sense. Even authentication alone is securer than encryption alone. > 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? 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. 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? > Of course, if you can just level the network and setup a secure > authenticated and encrypted DNS layer up to a trusted party, like your > own DNS server via VPN, google dns or opendns via this draft's method > plus an out-of-band public key for authentication, all the better. But > these are two very distinct cases. This is quite different. IMHO both authentication and encryption are the requirements for resolver privacy. > > But IMHO, in scenarios where authentication has priority than > encryption, opportunistic security is similar to not having any > security. In other words, exposal of domain names are not as important > as verification of the resolver. > > This draft says nothing about authenticity of DNS data. For that, there > is DNSSEC. > 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. Best, Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
