Subject: Re: [DNSOP] reservations on reservations, was Barry Leiba's Abstain

From: "John Levine" <[email-masked]>
Date: 1 Sep 2015 14:35:00 -0000

>This is a language quibble. I said ICANN had no mechanisms for
>specifying how a domain should be handled, and I would think a SHOULD
>specification is exactly that in formal language.

ICANN has vast sets of rules about how GTLDs are handled at the server
end.  They have rules about DNSSEC and about server redundancy and
multiple layers of rules about what can and cannot be in the zone
files.  Admittedly they're only binding on contracted parties, but if
you want rules, they got rules.  There are also individual TLDs with
more specific rules, notably .TEL which mostly has NAPTR records.

In any event, from the point of the DNS, a reservation that just says
don't resolve .onion would be quite adequate.  If someone else wanted
to invent another software package that also squatted on .onion to do
something else, it'd be confusing but it wouldn't cause new DNS
stability problems.

>And FWIW, [advice to reject .onion in applications is] not intended
>primarily as an optimisation in the sense of efficiency, rather its an
>attempt to mitigate a privacy leakage in the TOR system.

If you implement what this draft says, your local DNS resolver library
will reject .onion queries so there'll be no leakage.  I suppose we
might call it belt-and-suspenders.

R's,
John

---

From: David Cake <[email-masked]>
Date: Tue, 1 Sep 2015 23:35:09 +0800

> On 1 Sep 2015, at 10:35 pm, John Levine <[email-masked]> wrote:
> 

	But the point is they are binding only on contracted parties, and so inappropriate for undelegated TLDs. ICANN enforces its rules via contact only. So ICANN has no mechanism for specifying what happens to a non-delegated domain. All I’m saying is that delegation isn’t always the desired outcome for a special use domain, and the ability to specify how to handle the resolution of a non-delegated special use domain is useful, and provides a justification for using IETF rather than ICANN processes for such domains..
	Whereas ICANN processes provide a lot of useful specification for domains that are delegated, including many mechanisms (e.g. an ongoing compliance monitoring process) that IETF is not in a position to provide.

> don't resolve .onion would be quite adequate.

	You may consider the privacy leakage issues of no consequence. Others do not.

> might call it belt-and-suspenders.

	Indeed. And I consider including that advice to thus serve a useful purpose.

	David

---

From: "John R Levine" <[email-masked]>
Date: 1 Sep 2015 11:38:02 -0400

> 	You may consider the privacy leakage issues of no consequence. Others do not.

Please do not put words in my mouth.  They're important but they're not a 
DNS problem.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 1 Sep 2015 15:45:22 +0000

> Please do not put words in my mouth.  They're important but they're not a

I think reasonable people might disagree?

In my view and the DNS has a critical flaw: it does not provide query privacy.

All the best,
Jacob

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 01 Sep 2015 13:27:19 -0400

> In my view and the DNS has a critical flaw: it does not provide query 

You're on the wrong list. The people working on DNS privacy are over at 
DPRIVE. For the problem statement, see RFC 7626, recently published.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 1 Sep 2015 14:35:10 -0400

> I think reasonable people might disagree?

Not really.  It's a layering issue.

> In my view and the DNS has a critical flaw: it does not provide query privacy.

It can't be a critical flaw -- if it were we'd consider the DNS to be
broken and we wouldn't be using it.  It's certainly true that people
are using the DNS in environments that nobody imagined in the 1980s,
and some of those environments have desiderata like query privacy
that DNS classic doesn't.

Also please keep in mind that we're having this discussion because of
design tradeoffs in the implementation of Tor.  If they'd made onion a
URI scheme rather than a pseudo-domain, onion://blah rather than
http://blah.onion, there's be no leakage problem since browsers that
don't know about onion: would just reject them.  Using a pseudo-domain
made it possible to put the Tor implementation into a SOCKS proxy
which made the implementation a lot easier, but created the leakage
problem.

While I have a great deal of sympathy for the goals of the Tor
project, I do not think it is solely up to us to protect them and
their users from the consequences of their design tradeoffs.

Regards,

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 1 Sep 2015 21:55:30 +0000

> Not really.  It's a layering issue.

It is a design flaw from an era when fax machines roamed the earth.

> that DNS classic doesn't.

It is a critical flaw that fails open. The DNS continues to work but
users are put into harm's way. The lack of query privacy is a problem
that enables selector based surveillance unlike almost any other
protocol. I rarely, if ever, use DNS on networks directly as a client
as a result of these issues.

> which made the implementation a lot easier, but created the leakage

I'm aware of the context, I'm a co-author of the RFC in question. The
solution you present is not practical for integration across most
programs without huge modifications to nearly every program.

Or put another way:

  "The internet is more than the world wide web"

> their users from the consequences of their design tradeoffs.

The issue isn't just Tor. Our users are already protected - this is to
stop *other* users from shooting themselves in the foot. As it stands,
many users are under the false assumption that they the internet
actually has privacy properties without Tor.

All the best,
Jacob

---

From: "John R Levine" <[email-masked]>
Date: 1 Sep 2015 18:06:56 -0400

> programs without huge modifications to nearly every program.

That's what I said.  "It's more work than we were willing to do" is a 
reasonable criterion, but it's not the same as "it's impossible".

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 1 Sep 2015 18:15:44 -0400

Speaking of which ...

> users are put into harm's way. ...

>> don't know about onion: would just reject them. ...

> programs without huge modifications to nearly every program.

So, just to clarify, the DNS leaks and it's a critical flaw, but Tor 
applications leak and that's just the way it is?

I'm not opposed to mitigating the damage, but let's think more carefully 
about the stones we're throwing, please.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2015 08:28:10 +1000

In message <[email-masked]>, "Joe Abley" writ
> DPRIVE. For the problem statement, see RFC 7626, recently published.

DPRIVE are looking at stub to recursive resolver privacy.

This is recursive resolver to root server privacy which is off charter
for DPRIVE.

Now there are two ways to solve this as the root is signed.

1. Recommend *every* recursive server holds a copy of the root zone.
   This has implications for ICANN and how many TLD's they can sell
   as the root zone would need to remain relatively small.  This
   also helps with other leakage to the root zone.

2. Insecurely delegate .onion and recommend that every resolver
   synthesis a NXDOMAIN response.  This also has implication for
   ICANN as they don't have procedures to do this sort of delegation.

3. Hope that QNAME minimisation gets deployed to all stub resolvers.

2 and 3 both leak that a onion name is being looked up but not what that
name is.

> Joe
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 1 Sep 2015 22:39:23 +0000

> applications leak and that's just the way it is?

Tor doesn't leak .onion names. The DNS does share information with the
network as plain text. This critical privacy flaw is exploited by
perpetrators of mass and targeted surveillance for computer and
network exploitation purposes, amongst other issues.

> about the stones we're throwing, please.

I'm not intending to throw stones, sorry.

Tor doesn't leak .onions - other web browsers, ssh clients, jabber
clients and other software *may* leak .onions. Many users try to
resolve .onions in a variety of amazing ways, most of whom have never
used Tor, I'd guess. Tor currently handles .onions correctly and to my
knowledge is not responsible for leaking .onions, ever.

If the name is reserved and the process is followed, we'll hopefully
be able to stop most of the leakage in the DNS. This will mitigate
some of the damage caused by a lack of query privacy. It also allows
us to protect the intentional users of .onion by acknowledging their
usage and their deployment realities.

All the best,
Jacob

---

From: Ted Lemon <[email-masked]>
Date: Tue, 1 Sep 2015 19:00:36 -0400

On Sep 1, 2015, at 6:06 PM, John R Levine <[email-masked]> wrote:
> That's what I said.  "It's more work than we were willing to do" is a reasonable criterion, but it's not the same as "it's impossible".

I think it’s "fixing this would involve pervasively fixing a wide range of software we didn’t write and don’t necessarily have source code for, so while possible in theory, it is not possible in practice."

---

From: hellekin <[email-masked]>
Date: Tue, 1 Sep 2015 20:15:05 -0300

On 09/01/2015 07:39 PM, Jacob Appelbaum wrote:
> Tor doesn't leak .onions
> be able to stop most of the leakage in the DNS.
> 

One clear example that was documented earlier is the "pre-fetching"
feature of some Web browsers that will request links on a visited page
"to accelerate the Web" in anticipation of the user's next move (which
sounds quite wasteful indeed).  In this case, if a page mentions links
to .onion URLs, a browser that is not configured to use Tor will hit the
DNS root with an inappropriate request.  On the contrary, if the browser
is configured to use Tor, no leak will happen because the Tor resolver
will take precedence over DNS resolution for .onion.

Once the RFC is available, browser implementors can add a filter for
.onion to their prefetching code.  They certainly don't need the RFC to
do so, but once it's RFC, it's more likely that they do it.

==
hk

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 02 Sep 2015 09:15:59 -0400

On 1 Sep 2015, at 18:28, Mark Andrews wrote:

>>> In my view and the DNS has a critical flaw: it does not provide 
>>> query
>>> privacy.
>>

Sure, but several of the mechanisms that have been discussed to date 
could be applied to flows between forwarders and recursives, or between 
recursives and authorities.

Joe

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 2 Sep 2015 16:46:09 +0200

On Wed, Sep 02, 2015 at 08:28:10AM +1000,
 Mark Andrews <[email-masked]> wrote 

> 1. Recommend *every* recursive server holds a copy of the root zone.

The problem is more general than that. It is not only the root (well,
the sniffers along the path to the root name servers), it is a
recursive-to-authoritative problem. Your solution does not work for
.com or even .fr.

---

From: "John R Levine" <[email-masked]>
Date: 2 Sep 2015 11:25:18 -0400

> recursive-to-authoritative problem. Your solution does not work for

It seems to me there are two separate problems here.  One is channel 
security, preventing parties other than the two endpoints of the 
transaction from knowing its contents, which we know how to address by 
encryption, e.g. with TLS.

The other is query security, preventing the server from knowing who's 
asking the question, and ideally from knowing what question is being 
asked.  Applying Mark's suggestion recursively we end up back at 
HOSTS.TXT, a ship that sailed so long ago that its rotted timbers are now 
the subject of learned archaeological investigations.

Tor is one approach to query security that seems to work pretty well give 
or take side channel leakage.  Dunno if there are any others, but it is 
clearly a very hard problem, and not one we're going to solve any time 
soon.

Regards,

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Sep 2015 07:08:50 +0900

Stephane Bortzmeyer wrote:
>  Mark Andrews <[email-masked]> wrote:
>
>> ...
>>

right. however, if tcp-fastopen and tls are used for the
server-to-server traffic (cache misses), the ~30M recursives could each
have a permanently nailed-up TCP session to the ~10M authoritatives. i
don't love the resulting state load, but it would secure the top of the
flow.

-- 
Paul Vixie

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 2 Sep 2015 22:17:04 +0000

> On Sep 2, 2015, at 3:08 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 

I assume your ~30M number comes from open resolver scans and while you can
find that many addresses that will openly forward queries, they don't all
talk directly to authoritative servers.  In fact, those ~30M forward through
to about ~300K that then talk to the auths.

DW

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Sep 2015 07:20:57 +0900

John R Levine wrote:
> ...
>
> Tor is one approach to query security that seems to work pretty well
> give or take side channel leakage.  Dunno if there are any others, but
> it is clearly a very hard problem, and not one we're going to solve
> any time soon.

i think we have to be realistic. the national security apparatus of the
largest dozen economies have effectively unlimited resources. they will
spend as many of our tax dollars as it takes to buy as much equipment
and talent and methodology and electric power as it takes to watch what
they decide is important to watch.

i'm all for PFS on the cache miss path, but trying to hide who the query
came from so that an authority server has less insight, is nutball
stuff. remember that the NSA (et al) is a form of "us" and that we will
not stop "us" with math. real change there will come in the voting booth.

-- 
Paul Vixie

---

From: Ian Maddison <[email-masked]>
Date: Thu, 3 Sep 2015 02:12:26 +0200

> On 03 Sep 2015, at 00:20, Paul Vixie <[email-masked]> wrote:

> NSA (et al) is a form of "us" and that we will

t-shirt idea !

almost beats Jacob saying the special use request for .onion is for those who’ve probably never used Tor :)