Re: [perpass] DNS confidentiality

[manning bill <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass