Re: [perpass] DNS confidentiality

["Hosnieh Rafiee" <[e-mail]>]

 
>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