>1. Passive surveillence of traffic going to DNS resolvers yielding meta-data.
Again not possible, at least not in IPv6 if your resolvers and recursive resolvers are using cga-tsig. The signature and the CGA/SSAS algorithm prevent it. >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. Again this is not possible if you are using cga-tsig. > 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. If you are using SeND with SSAS or centralized RPKI you can retrieve and verify your router in a local link. RA can include the (http://tools.ietf.org/html/rfc6106) DNS server options. This means that you receive a signed message from a router that was previously authorized via the centralized local RPK1. I am not sure whether or not DHCPv6 also includes security approaches that can be used for authentication. I believe that there was a draft about secure authentication using CGA in DHCPv6 as well. You can also us a scenario, like SSL, to verify your router certificate where the client has already configured the list of CAs. >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. I guess that you did not quite understand the reasoning behind CGA and that is why you are asking a question about an issue that I have already explained. Your client retrieves this IP address from the RA message that is generated by the use of SeND with the DNS RA option (. Since this RA message is already signed and we assume that this client has already verified this router (centralized local RPKI that is explained in SSAS or other RPKI approaches) the attacker has no way of spoofing this message as it cannot spoof the content (due to the signature) and it cannot spoof the public key due to the binding between the public key and the source IP address >How does this prevent MITM from inserting himself between the client and the resolver on the first connection to the resolver? Your node already knows the IP address of your 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. As I explained, you retrieve the IP address of your DNS server using a safe means after having authorized your router in the local link. Now if your MITM node is somewhere in the other network and tries to intercept the connection between your node and the resolver, since you node already knows the IP address of the resolver, it will reject the connection because the CGA/SSAS verification process fails. >Whom does the client "ask for the public key of the DNS server" from? This is the step that is subject to MITM attack. I guess I have already responded this. Hosnieh _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
