you are conflating routing security/authentication with DNS service opaque capabilities. there already exist a number of methods for securing the DNS channel, [SIG(0), TSIG, DNSCurve…] and we can add your technique to the list.
protecting the service is very different than protecting the channel. /bill On 27September2013Friday, at 12:21, Hosnieh Rafiee wrote: > > >> 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 _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
