Re: DNS64, DANE and DPRIV

[Mark Andrews <[e-mail]>]

In message <[e-mail]>
, Phillip Hallam-Baker writes:
> 
> Following up on the DNS64 discussion. There is an important action item
> that IETF can take right now that has a lot of leverage for IPv6
> deployment.
> 
> * DPRIV be required to provide a mechanism for mutual authentication as
> well as confidentiality.
> 
> This is not a major increase in scope. Authentication is essential for
> confidentiality. But it is a big improvement in leverage.
> 
> 
> The idea of DPRIV is that instead of sending requests to a random DNS
> resolver in plaintext, we instead send them encrypted. And by implication
> we also direct them to a resolver that can be trusted not to disclose the
> traffic to an attacker.
> 
> So in the DPRIV model, the resolver is trusted. I suggest that there are in
> fact quantized levels of trust.
> 
> 0) Service: To provide responses to requests
> 1) Confidentiality: To not disclose traffic to third parties
> 2) Routing Integrity: To provide A and AAAA record responses that connect
> traffic to the correct end point
> 3) Security Integrity: To provide keys for the end points.
> 
> Now depending on how much processing you are prepared to put in the client
> you can reduce the level of trust. But you do need more code (or human
> intervention).
> 
> So it is in theory possible to use DNSSEC to avoid the need to rely on the
> resolver to return responses but I have never seen that done in a
> completely robust fashion because it would require a lot of code and a lot
> of corner cases.
> 
> The point of DNS64 is to provide a mechanism that makes it easy to turn on
> IPv6 today. All the client needs is a connection to a DNS router that
> supports DNS64.
> 
> 
> Because of network circumstances a client using DNS64 is almost certainly
> going to need to use DPRIV for access simply because port 53 has been
> sabotaged so thoroughly. So we are going to have to trust the DPRIV
> resolver to level 1 at minimum
> 
> The fact that we are considering DNS64 at all implies that we are willing
> to trust the resolver to level 2. But to do that we have to have
> authentication of the resolver at minimum and I would argue that mutual is
> also necessary for enterprise deployment.
> 
> As soon as we have DPRIV with authentication it becomes possible to ship
> IPv6 only products today. The only facility those products require to
> connect to the IPv4 Internet is a DPRIV connection to a DNS resolver that
> offers DNS64.
> 
> 
> Note however, that trust to level 2 does not entail trust to level 3. An IP
> address and a Key or Key fingerprint are two very different things. A Key
> or Key fingerprint is an authenticator. An IP address is not an
> authenticator, or at least it is a very weak one whose interpretation
> requires us to trust a great deal more than our resolver.

Phillip,
	I don't trust my or any ISP to not alter DNS responses.
Too many ISP have done that in the past and continue to do so.  For
that among other reasons I run my own validating resolver.

If my ISP decides to run NAT64 + DNS64 then I need to be able to
get the DNS64 parameters securely for which there is no solution
today.  Additionally there is no easy mechanism which doesn't require
me to funnel all my DNS queries through the ISP's nameservers despite
me not wanting to send any queries to them at all.  I am not alone
with this desire.  Millions of people already don't use their ISP's
nameservers but instead use a third party or run their own.

DNS64 was driven, in part, from the desire to do something that
didn't require changes in the node.  It failed to achieve that
and as far as I can tell there is no solution that could achieve
that.

DNS64 is not the only solution for a ISP to go IPv6 only.  DS-Lite
allows that.  It also doesn't force you to use the ISP's nameservers
and it doesn't break DNSSEC.

Can we just give up on DNS64 as a general solution to going IPv6
only.  It has its niche place in the cell phone world.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]