Paul, > > > 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)
Well... I guess you are answering yourself .. I did not have any discussion about data integrity and also the second paragraph is all what I tried to tell you ... So I only answered your comment and explained that I did not talk about data integrity. So not sure what is the problem here!?? :-/ > >>> 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. I guess we are not on a same page... are we discussing about resolver privacy or the web application or email privacy? Can you please explain to me what you expect to encrypt in resolver privacy scenario? I thought the encryption is only some domain names, IP address or the labels available on DNS server. The things that DNS server send it back to the node. What you are talking here seems to be about web application privacy because if the first point doesn't fail (use opportunistic or whatever other approaches) then you are right that the attacker doesn't have the possibility to play MITM attack. But when you are talking about the resolver, you receive the IP address of one of attacker's server from this bad guy or good guy that can be inside your own network. For example, You want to connect to google.com. your computer sends a request to resolver x with IP address 192.168.1.1. You will exchange the key information with this resolver. The good or bad guy called eve intercepts this communication and sends its own key and spoof the legitimate resolver IP address. Your poor node doesn't have any possibility to authenticate this resolver. So, your computer accepts eve's computer as the resolver and accepts any IP address eve gives to your computer. So, eve gives the IP address of one of her servers instead of google server. So, your computer sends all packets to this computer instead of sending it to the real google server and this computer forward it to real google server. So eve in this scenario only eavesdrops all the communications. Even though google server uses a valid certificate. But eve computer established this secure connection to google server. So your computer established a fake secure connection to google webserver while eve is in between an d receives all the packet, decrypt it and then again send it to google server. Your computer can never understand this problem since it has no possibility to authenticate this resolver. Did you solve privacy? Eve or who ever in between listened to all traffic. If you are using your home network and there is no other person who might be interested in your query send to this resolver, then why do you encrypt? If there is a likelihood of having eavesdropper in the network, that eavesdropper can directly answer your query and claim to be a resolver so again why do you encrypt? So what I think is that encryption and authentication both are necessary components for resolver DNS privacy. > >> 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. But that person in wifi can also claim to be a resolver and directly receive your information. Like my example with eve. So I do not see any privacy protection. > > 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??? Nope, Joel already responded you. DNSSEC cannot protect you in this case. If it could, they could also use it now and there was no need for any other proposals. > >> 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. The important thing is whatever is in your query is not protected only by encryption because whoever you afraid to retrieve these data can introduced itself as a resolver and directly receive the data that you are afraid to expose it. > > 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.... Please see above.. this avoid repeating the same sentence. Do not misinterpret what I said. I said both Encryption and Authentication is necessary and only encryption does not help because of the reasons I repeated in this message and last messages. > > 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. This is again my opinion. There is no passive attacks on resolvers. Your node once get some information and then if this information is wrong you are in trouble because you are connected via MITM. So the attacks is only once during when the time your node itself ask for a query. After that, everything is finished. And your node uses different approaches to connect for instance to a website or to a server. It appears that you think the resolver is last point of connection. The resolver is only the point which provide you information. It can be wrong or right. If it is right then the whole connection would be secure because you received the IP address of a correct server. Then the passive attack is for that part which is not related to resolver. The attacker might try to eavesdrop the data exchanged between you and a website. If the website is secure and you obtained the Ip address of this website securely from this resolver then the passive attack is protected as well but if there was MITM , you already have a MITM and encrypted connection to that website doesn't make sense otherwise that website uses a CA. Then your browser might give you a message that it cannot detect this IP certificate (because it is for attacker node). So this part is out of scope of resolver privacy scenario. If this is not correct, please explain to me a passive attack scenario for resolver. So again, I think passive attacks in resolver scenario tightly coupled to the first active attack and then whether the website or server that you obtained this IP address from, supports a valid CA. > > 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. And any attack is possible.. this is why there is some new approaches like SAVI to protect DHCP > > 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. Ok then I am an attacker, since you cannot authenticate me, I sign the data myself. This has data integrity. But it is the modified data and not what you expected to receive... Hosnieh _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
