Karl, The subject line is about confidentiality. If you (or others) want to disucss other security issues with DNS, please first read up on DNSSEC and then start new threads.
Now, can we get back to discussion of subject of the subject line? Thanks, S. On 09/28/2013 04:27 PM, Karl Malbrain wrote: > The routers being controlled by the larger adversary are the ones that take > traffic into and out of the geographic area. The adversary is re-routing all > traffic to DNS ports to his bogus DNS server and replying with IP address > spoofing -- e.g. a MITM attack on DNS traffic. > > DNS needs some means of authentication to prevent this. Certificates can be > forged. TOFU doesn't work either. > > The routers are completely programmable by MITM -- they don't have any > security that I know of. > > > > ________________________________ > From: manning bill <[email protected]> > To: Hosnieh Rafiee <[email protected]> > Cc: 'perpass' <[email protected]>; 'Karl Malbrain' <[email protected]>; > 'Stephen Farrell' <[email protected]> > Sent: Saturday, September 28, 2013 3:02 AM > Subject: Re: [perpass] DNS confidentiality > > > 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 > > > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
