I'm concerned about three DNS security problems: 1. Passive surveillence of traffic going to DNS resolvers yielding meta-data. 2. MITM who inserts himself between a particular DNS client and a particular DNS resolver, and provids false addresses and certificates for use in MITM attacks. 3. A larger adversary who installs his own DNS resolver for a given geographic area by controlling the traffic at the router level into and out of that area to redirect DNS traffic to his DNS resolver, and then inserts MITM attacks on any connection out of the area he desires by supplying bogus addresses and/or server certificates. I'm not concerned at this time about an even larger adversary capable of surveillence of all traffic in a given geographic area, yielding a complete set of meta-data.
>The client doesn't need to retrieve their public key from anywhere. They >generate it themselves. This is the actual case with CGA-TSIG. So how does >it work you ask? It is dependent on the scenarioes. The client is trying to retrieve the IP address and public key for an arbitrary server from the DNS resolver. This is subject to MITM attack. >For the resolver scenario: >The client knows the IP address of the resolver because it was obtained from >a DHCP server or a RA message. When, for the first time, the client wants to >resolve its query and the resolver answers, the client finds the binding >between the IP address and the public key, which is generated by the DNS >server itself. How does this prevent MITM from inserting himself between the client and the resolver on the first connection to the resolver? > This is actually a capability of CGA (RFC 3972) or SSAS >(http://tools.ietf.org/html/draft-rafiee-6man-ssas ), which also provides >for the proof of address ownership. So, the client stores the public key of >the resolver in its cache. It will subsequently not accept any messages from >attackers. What if the public key being stored belongs to MITM and not the resolver? All client traffic is going to MITM. > Why? >Because the attacker doesn't have the private key of the node that he needs >in order to spoof the message and since the public key that is involved in >the address generation using both algorithms, then it is not possible for >the attacker to spoof this IP address and make use the public key of the >resolver. MITM provided his public key in the first connection from the client. >We also have a paper which discusses the possibility of encrypting the >message using the DNS server public key. Please refer to this paper >(http://www.hpi.uni-potsdam.de/fileadmin/hpi/FG_ITS/papers/Trust_and_Security_Engineering/2013_Rafiee_NCA.pdf > ). > This is more applicable to the DNS >update (zone transfer, FQDN) scenario. This means that the client first asks >for the public key of the DNS server. When using the CGA/ SSAS algorithm, a >binding is found between the public key and the IP address of the DNS >server. The client then generates a shared secret, encrypts it using the >public key of the DNS server, and generates the update message, encrypts it >using this shared secret (symmetric encryption - algorithm like AES), and >submits it to the DNS server. Since the attacker doesn't know the content of >message, it cannot play a role of MITM when using the FQDN scenario for the >first time. Whom does the client "ask for the public key of the DNS server" from? This is the step that is subject to MITM attack. Karl Malbrain
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
