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
