Subject: DNS64, DANE and DPRIV

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Dec 2014 12:45:13 -0500

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.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 07 Dec 2014 08:35:51 +1100

In message <[email-masked]>
> 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: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sat, 6 Dec 2014 17:02:48 -0500

On Dec 6, 2014, at 12:45 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> * DPRIV be required to provide a mechanism for mutual authentication as well as confidentiality.

You mean TSIG?   Or SIG(0)?

---

From: Randy Bush <[email-masked]>
Date: Sun, 07 Dec 2014 07:19:39 +0900

> DNS64 is not the only solution for a ISP to go IPv6 only.

64 was motivated by the need for a 6-only *enterprise*

> DS-Lite allows that

ds-lite is the ideal solution.  it combines nat in the core with (for
most providers) fork-lift of the cpe.  what could be wrong with that?

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Dec 2014 17:45:10 -0500

Neither. DPRIV is specifying a new transport that can authenticate directly. SIG would only get in the way 

Sent from my difference engine

> On Dec 6, 2014, at 5:02 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Mark Andrews <[email-masked]>
Date: Sun, 07 Dec 2014 10:58:36 +1100

> most providers) fork-lift of the cpe.  what could be wrong with that?
 
And DNS64 requires NAT in the core and a fork lift upgrade of the
CPE to support IPv6.

---

From: Randy Bush <[email-masked]>
Date: Sun, 07 Dec 2014 09:01:02 +0900

> And DNS64 requires NAT in the core and a fork lift upgrade of the

no.  let's try reading what i said again.  i requires nat at the edge of
the V6-ONLY ENTERPRISE.  considering the enterprise is v6-only and
trying to talk to a v4 world, address translation is inevitable.

randy

---

From: Mark Andrews <[email-masked]>
Date: Sun, 07 Dec 2014 11:23:34 +1100

> trying to talk to a v4 world, address translation is inevitable.

Yet we have ISPs trying to use / contemplating using DNS64.

DS-Lite in the enterprise would require moving DL-Lite to the node
and not all nodes.  Just those that need to communicate with the
outside world.  For most of those boxes it's just a reuse of existing
stack functionality.

---

From: Randy Bush <[email-masked]>
Date: Sun, 07 Dec 2014 09:50:02 +0900

> Yet we have ISPs trying to use / contemplating using DNS64.

we have isps using nat4444, ds-blight, ...,  kids shooting crack,
imperialists bombing people half a plaet away.  so?

> DS-Lite in the enterprise would require

see crack above

randy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 6 Dec 2014 20:09:39 -0500

> trying to talk to a v4 world, address translation is inevitable.

Actually it requires NAT, the NAT does not need to be at the egress point
from the network. It could be provided by a NAT tied to the destination
network.

Mark we avoid talking in acronyms? What is this CPE requiring a fork lift
truck? And what does Nintendo have to do with this?

If you spell out the acronym Network Address Translation, it becomes
obvious that Randy is right - it has to happen somewhere.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 6 Dec 2014 20:26:33 -0500

On Sun, Dec 07, 2014 at 08:35:51AM +1100, Mark Andrews wrote:
> today.

You mean, "Get the Pref64 securely"?  There is in fact a solution for
that, and it is in RFC 7050.  Moreover, it can be secured if the ISP
is not using the WKP.  So, if you're willing to do the DNS64 function
yourself and your ISP isn't using the WKP, you can have secure
answers.  (For all that, if your ISP _is_ using the WKP, then you
don't need to look it up securely.)

> only.

I should hope so.  It was never intended to be a general solution, and
I think we who worked on it were crystal clear about that all along.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 07 Dec 2014 18:04:17 -0500

> IPv6 today. All the client needs is a connection to a DNS router that

You worded that wrong.
DNS64 lets people turn off IPv4 (and/or avoid NAT4*4).

    > resolver to level 1 at minimum

That's an interesting observation: can you elaborate on the sabotage?
I think I know, but I'd rather you were more clear about this.

I've wanted DNS64 to happen in the host, and given that a number of hosts had
to be fixed to function in IPv6 only environments, a change to include DNS64
would not be crazy in my opinion, and eliminates much of the end-to-end
DNSSEC-breakage that DNS64 can imply.

(or to put it another way: when you turn on end-host DNSSEC validation,
and enable DPRIV, you had better provide DNS64 at the same time)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 7 Dec 2014 20:14:41 -0500

> and enable DPRIV, you had better provide DNS64 at the same time)

For whatever it's worth, my view when we were working on DNS64 was
that DNSSEC wasn't really deployed for edge validation yet, so if one
had to make a change in something to accommodate DNS64 it would be ok
if it was part of the way validation at the edge happened.  I think
that is still true, and I think therefore that DNS64 at edge hosts is
not a terrible idea.  Moreover, if the edge device knows about the
NAT64, it's in a position to do less stupid stuff itself.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 7 Dec 2014 22:56:13 -0500

> DNS64 lets people turn off IPv4 (and/or avoid NAT4*4).

Turn off or not have the code in the stack at all. Yep.

For a lot of embedded devices, I think this is the ideal. They don't really
need full Internet connectivity in any case. They might have a ten or
twenty year service life though so I care rather more that they are IPv6
capable than a desktop that might last seven years tops.

> I think I know, but I'd rather you were more clear about this.

There are two types of sabotage: Ignorance and malice.

Ignorance includes stupidity like chopping DNS messages to 512 (sometimes
500) bytes, filtering out unknown RRs and such. And the usual IETF approach
is to wait for people to learn better (hey we have been waiting 40 years...)

Malice is increasingly common though. Like when I found my ISP had
redirected ALL port 53 traffic through their own resolver so they could do
a sitefinder hack if NXT showed up. The DNS is a powerful control point,
people will make use of it unless it is properly secured.

You can't ignore or wish away malice when writing a security spec.

I have been arguing that DNSSEC requires a new client resolver protocol to
be practical for ten years now. And the need has only increased.

> and enable DPRIV, you had better provide DNS64 at the same time)

This bit isn't clear to me.

My main point is that if you are playing NAT64 games and example.com only
has an A record, then a DNSSEC signature on the A record is like a
chocolate teapot to an IPv6 only device.

Sure we could come up with some mechanism for describing the NAT64 mapping
so that the end host could read it. But where would the mapping come from,
who would sign that? Doing validation in the client does not actually
provide leverage here.

Perhaps what would help here is a trust calculus that would expose what the
assumptions are that a device is relying on. The problem with PKI is that
it is so easy to add a layer of indirection.