Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread John R Levine 

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


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Renumbering and glue record updates

2015-09-01 Thread Mark Andrews 

In message <55e63378.3010...@mirix.org>, Matthias-Christian Ott writes:
> Since 6renum is concluded I thought this WG could most likely help to
> address the following problem:
> 
> If the IPv6 network of an authoritative nameserver is renumbered and the
> parent zones of zones that are served by the nameserver contain glue
> records for the nameserver, the glue records need to be changed as well.
> As described in RFC 7010, the nameserver could update the glue records
> through Secure Dynamic DNS Updates and the nameserver of the parent zone
> could restrict dynamic DNS updates to the  RRs for the name of the
> nameserver through ACLs (principle of least privilege). So in theory the
> problem the problem is solved.
> 
> In practice subdomains registered under public suffixes do not allow
> dynamic DNS updates. Glue records and NS records can only be changed
> through EPP or proprietary protocols of the respective registries and in
> some cases only through fax or letter. Most registrars expose their
> interface to the registry, including glue record management, directly to
> registrants either through a self-service web interface that can be
> scraped, EPP or some proprietary protocol and only few require
> interaction with their customer support. So it is still possible to
> automatically update the glue records of a nameserver when its network
> is renumbered. However, there is no fine-grained access control - even
> if you interface directly with the registry. That means that you have to
> store the credentials that can be used to change all details of your
> domain in the registry on every nameserver if you want that nameserver
> to be able automatically update its glue records. If your domain uses
> DNSSEC with separate KSK and ZSK, it suffices to compromise a secondary
> nameserver to replace the KSK which undermines the security model.
> 
> After some thinking the only countermeasure that I could come up with is
> to either to have a trusted gateway to the registrar/registry that you
> assume to be secure and highly-available or monitor the registry for key
> changes and have an emergency plan to limit the damage. Both
> countermeasures seem unsatisfactory to me.
> 
> Obviously registries and registrars could introduce more fine-grained
> access control but I doubt that this is going to happen, especially
> considering the interfaces provided by registrars.
> 
> Has this problem been addressed somewhere or is there an ongoing effort
> that would address it?

https://datatracker.ietf.org/doc/draft-andrews-dnsop-update-parent-zones/

Provided a mechanism to do this which allowed fine grain access control
base on tsig / sig(0) name.

It could also use SIG(0) instead of TSIG though the draft doesn't state
that.

> - Matthias-Christian
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Renumbering and glue record updates

2015-09-01 Thread Matthias-Christian Ott 
Since 6renum is concluded I thought this WG could most likely help to
address the following problem:

If the IPv6 network of an authoritative nameserver is renumbered and the
parent zones of zones that are served by the nameserver contain glue
records for the nameserver, the glue records need to be changed as well.
As described in RFC 7010, the nameserver could update the glue records
through Secure Dynamic DNS Updates and the nameserver of the parent zone
could restrict dynamic DNS updates to the  RRs for the name of the
nameserver through ACLs (principle of least privilege). So in theory the
problem the problem is solved.

In practice subdomains registered under public suffixes do not allow
dynamic DNS updates. Glue records and NS records can only be changed
through EPP or proprietary protocols of the respective registries and in
some cases only through fax or letter. Most registrars expose their
interface to the registry, including glue record management, directly to
registrants either through a self-service web interface that can be
scraped, EPP or some proprietary protocol and only few require
interaction with their customer support. So it is still possible to
automatically update the glue records of a nameserver when its network
is renumbered. However, there is no fine-grained access control - even
if you interface directly with the registry. That means that you have to
store the credentials that can be used to change all details of your
domain in the registry on every nameserver if you want that nameserver
to be able automatically update its glue records. If your domain uses
DNSSEC with separate KSK and ZSK, it suffices to compromise a secondary
nameserver to replace the KSK which undermines the security model.

After some thinking the only countermeasure that I could come up with is
to either to have a trusted gateway to the registrar/registry that you
assume to be secure and highly-available or monitor the registry for key
changes and have an emergency plan to limit the damage. Both
countermeasures seem unsatisfactory to me.

Obviously registries and registrars could introduce more fine-grained
access control but I doubt that this is going to happen, especially
considering the interfaces provided by registrars.

Has this problem been addressed somewhere or is there an ongoing effort
that would address it?

- Matthias-Christian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread Jacob Appelbaum 
On 9/1/15, John R Levine  wrote:
>>> Please do not put words in my mouth.  They're important but they're not
>>> a
>>> DNS problem.
>>
>> I think reasonable people might disagree?
>
> Not really.  It's a layering issue.

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

>> 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.

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.

>
> 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.

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"

>
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread Jacob Appelbaum 
On 9/1/15, John R Levine  wrote:
> Speaking of which ...
>
>> It is a critical flaw that fails open. The DNS continues to work but
>> users are put into harm's way. ...
>
>>> 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. ...
>
>> 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.
>
> 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?

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.

> I'm not opposed to mitigating the damage, but let's think more carefully
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Ben Campbell's Yes on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

2015-09-01 Thread Ben Campbell 
Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/



--
COMMENT:
--

This one took some soul searching. But I think the arguments have been
made, and that on the whole this registration does more good than harm.

I agree with the several people who have pointed out that
[tor-rendezvous] should be a normative reference.

Nit: The abstract could use a bit more meat. For example, that the .onion
special-purpose name is for use with Tor.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread hellekin 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/01/2015 07:39 PM, Jacob Appelbaum wrote:
> 
> Tor doesn't leak .onions
> 
> If the name is reserved and the process is followed, we'll hopefully
> 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJV5jFpXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9n5sQAKRzvkBwJ/ibOoRlajG5AsRu
ACnykyUsP9aU2Hpv0kJFm7AvfKOy0gwHeYfWY/czjbvsC6X5sJ/Hoe+ZYUcPTwGQ
hjsug0m/F4htS4s6O5WbzLwc3506kmzw2PvyGzvJBpKZzgGU2gvn4H0JuVHemMXR
yNaQw21MFJIWOlhO0eshMr84SBoiaoO6IWEBjiITdtq1qsZNhPQRipn63r8VY2ul
mDTPSUcHvN4sblj2kiCCNVt0O8j6GhS3xc9H+EVe8Iz+Rk3hDbJtxBKZhSOZY309
YEjUhlkQ7CgmkTQa0fxEQsjSq3HSjLcfBCXkovCbt0i7ReEHP/YPr4cFtfWZIk7v
+Wnk1PuMI17SPnyglWiZxl3eLT0h4j4mxlrEAvT1TkeHmTu1CItTm9xcxuksdErS
3ncZPsUZAOObrw01tZVJ0YmF3kT4F5NE1ThlxrDIA9ygPT5cqgwAlXo+6thjff7y
dgaWi5swXYzzFh68KTgMxP8rWzItM+hV4k0SjYEXNVlYKLBKtUqFIaR0jNatVDN2
1Auy3p9+h+iw2DQnBDXtWMiQ6CprG/yn3yEsVueSobnwX8sNHHMRsIadifjAlh50
CnyYxb1BKuwkoJ61eHymKcDAD6Bz5i+gtpfEfBBxC5yzibQq8Dm/rNGMioyzz8k7
Bk6aSDSHHwq9P/0ZBxAb
=F5Fc
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread John R Levine 

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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2015-09-01 Thread Mark Andrews 

In message , "Joe Abley" writ
es:
> 
> 
> On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
> 
> > In my view and the DNS has a critical flaw: it does not provide query 
> > privacy.
> 
> 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.

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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread Ted Lemon 
On Sep 1, 2015, at 6:06 PM, John R Levine  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."

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] a long way from reservations on reservations, was Barry Leiba's Abstain

2015-09-01 Thread John R Levine 

Speaking of which ...


It is a critical flaw that fails open. The DNS continues to work but
users are put into harm's way. ...



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. ...



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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2015-09-01 Thread John Levine 
>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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2015-09-01 Thread David Cake 

> On 1 Sep 2015, at 10:35 pm, John Levine  wrote:
> 
>> 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.

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.

> In any event, from the point of the DNS, a reservation that just says
> don't resolve .onion would be quite adequate.

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

>> 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.

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

David



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2015-09-01 Thread Jacob Appelbaum 
On 9/1/15, John R Levine  wrote:
>>> In any event, from the point of the DNS, a reservation that just says
>>> don't resolve .onion would be quite adequate.
>>
>>  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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop