Subject: [hrpc] cases -> DNS

From: Niels ten Oever <[email-masked]>
Date: Wed, 07 Oct 2015 02:25:32 +0200

Hi all,

As laid out in our methodology, and discussed in Prague, we were going
to document cases of in which protocols could strenghten or harm human
rights (especially freedom of expression and/or freedom of assembly).
We found two people ready to document cases in which protocols
(potentially) strengthen or weaken human rights. Welcome on the list
Will and Nex. After a discussion we decided to look into some of the
following protocols: DNS [0], IP, VPN [1], HTTP, XMPP, TLS, mesh [2]
and PPSPP [3].

Please find underneath the first draft by Will on DNS, all input is
welcome of course. Tomorrow I will try to clean up the methodology
draft as discussed and insert it in there. In the mean time all
inputs, comments, questions and discussion points are very welcome!

Best,

Niels

[0] https://www.rfc-editor.org/rfc/rfc7626.txt
[1] http://www.vpnc.org/vpn-standards.html
[2] https://tools.ietf.org/html/rfc2973
[3] https://www.rfc-editor.org/rfc/rfc7574.txt

DNS
=====

The Domain Name System (DNS), as specified in RFC 1035, acts as a core
switchboard for the internet - associating human readable names with
services. The DNS system operates a centralized core of ‘Root
Resolvers’ , servers run by a set of organizations trusted by IANA to
enact the organization’s decisions by accurately communicating which
organizations have been delegated to manage registration under each
Top Level Domain (TLD). Top Level domains are maintained and
determined by IANA, and have evolved to encompass several classes of
services. Some, like ‘.Com’ and ‘.Net’, provide a common space for
expression of ideas, though their policies are enacted through US
based countries. Other name spaces are delegated to specific
nationalities, and may impose limits designed to focus speech in those
forums both to promote speech from that nationality, and to comply
with local limits on expression and social norms. Finally, the system
has been recently expanded with the addition of “generic TLDs”, name
spaces with accompanying regulations aimed to promote expression
around specific topics, for instance ‘.travel’ and ‘.ninja’.

DNS has significant privacy issues, as described in RFC 7626. Notably
amongst these, the protocol does not offer either encryption to limit
the visibility of requests for domain resolution from several
intermediary parties, nor does it offer authentication, allowing the
client to know that they have received a correct, “authoritative”,
answer to a query. Together, these decisions have resulted in ongoing
harm to freedom of expression as the DNS protocol has become one of
the central mechanisms used to block access to websites - limiting
both the freedom of expression of the publisher to offer their
content, and the freedom of assembly for clients to congregate in a
shared virtual space.

There have been several mechanisms used impose these limitations based
on the technical design of the DNS protocol. These have led to a
number of situations where limits on expression have been imposed
through subversion of the DNS protocol. Each of these situations has
accompanying aspects of protocol design enabling those limitations.

Removal of records
- -----
There have been a number of cases where the records for a domain are
removed from the name system due to real-world events. Examples of
this removal include ‘seizure’ of names of illegally operating
gambling operations by the United States ICE unit by compelling the
US-based registrar in charge of the .com TLD to hand ownership of
those domains over to the government. The same technique has been
notably used by Libya to remove sites in violation of “our Country’s
Law and Morality [which] do not allow any kind of pornography or its
promotion.”

At a protocol level, the ability to seize domain names is enabled by
the lack of transparency into DNS transfers, or any technical encoding
of name ownership. Name ownership is purely a policy decision of
registrars. While DNSSEC addresses distortion events described below,
it does not tackle this problem, which is has the cooperation of (or
compels) the registrar.

Documentation of this form of harm:
[1] http://news.bbc.co.uk/2/hi/technology/7250916.stm
[2]
http://techyum.com/2010/10/official-vb-ly-link-shortener-seized-by-libya
n-government/

Distortion of records
- -----
The most common mechanism by which the DNS system is abused to limit
freedom of expression is through manipulation of protocol messages by
the network. One form occurs at an organizational level, where client
computers are instructed to use a local DNS resolver controlled by the
organization. The DNS resolver will then selectively distort responses
rather than request the authoritative lookup from the upstream system.
The second form occurs through the use of deep packet inspection,
where all DNS protocol messages are inspected by the network, and
objectionable content is distorted.

At the national level, there are additional considerations. The most
notable is the interactions between DNS distortion and internet
routing. A study on collateral damage showed that the restrictions
imposed by China on DNS responses in its network also affected the
availability of sites to users in Germany, since some fraction of
requests would transit through the Chinese network, even though none
of the participants were located there.

A notable instance of distortion has occurred in Greece [3], where a
study found evidence of both of deep packet inspection to distort DNS
replies, and overblocking of content, where ISPs prevented clients
from resolving the names of domains which they were not instructed to
do through the governmental order prompting the blocking systems there.

At a protocol level, the effectiveness of these attacks is made
possible by a lack of authentication in the DNS protocol. The DNSSEC
protocol is not widely in use, but provides an extension allowing the
client to know that a response is ‘Authoritative’ - that it has been
generated by the server which has technical ownership of the name
requested. Even still, there are a range of downgrade attacks, where a
client may continue to follow the resolution of an injected message
without such a signature, since it may not know that it should expect
the response to be signed. Selective distortion of records has also
been made possible by the predictable structure of DNS messages, which
make it computationally easy for a network device to watch all passing
messages even at high speeds, and the lack of encryption, which allows
the network to distort only an objectionable subset of protocol messages
.

Documentation of this form of harm:
[1] http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf
[2] http://policyreview.info/articles/analysis/internet-censorship-turke
y
[3]
https://www.usenix.org/system/files/conference/foci15/foci15-paper-verve
ris-update.pdf
[4] https://tools.ietf.org/html/draft-hall-censorship-tech-01

Injection of records
- -----
Responding incorrectly to requests for name lookups is the most common
mechanism that in-network devices use to limit the ability of end
users to discover services. A deviation which accomplishes a similar
objective, though may be seen as different from a freedom of
expression perspective, is the injection of incorrect responses to
queries.  The most prominent example of this behavior occurs in China,
where requests for lookups of sites which have been deemed
inappropriate will trigger the network to respond with a bogus
response, causing the client to ignore the real response when it
subsequently arrives. Unlike the other forms of discussion discussed
above, injection does not stifle the ability of a server to announce
it’s name, it instead provides another voice which answers sooner.
This is effective because of the DNS protocol’s decision to provide
whatever answer it receives first, and stop listening for subsequent
answers, and enabled by the lack of authentication or encryption in
the protocol.

Documentation of this form of harm:
[1]
https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.p
df

- -- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                   678B 08B5 A0F2 636D 68E9

---

From: Hanane Boujemi <[email-masked]>
Date: Wed, 7 Oct 2015 10:14:00 +0200 (CEST)

Hi Niels,

I found the doc on DNS privacy consideration quite useful, do you have plans to produce visuals or videos which can explain in a simplified way the "potential" risk.. it could be useful for HR advocates?

Hanane

----- Original Message -----
From: "Niels ten Oever" <[email-masked]>
To: [email-masked]
Sent: Wednesday, October 7, 2015 2:25:32 AM
Subject: [hrpc] cases -> DNS

Hi all,

Best,

Niels

DNS
=====

Removal of records
- -----

Distortion of records
- -----

Injection of records
- -----

- -- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

_______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: Rafik Dammak <[email-masked]>
Date: Wed, 7 Oct 2015 17:27:32 +0900

Hi Hanane,

AFNIC usually published some easy-to read document about DNS for public
https://www.afnic.fr/medias/documents/afnic-dns-attacks-security-guide-2009-06.pdf
. maybe not necessarily targeting activists .
maybe other registry operators and DNS providers have such material too.

Best,

Rafik

2015-10-07 17:14 GMT+09:00 Hanane Boujemi <[email-masked]>:

> Hi Niels,
>
> I found the doc on DNS privacy consideration quite useful, do you have
> plans to produce visuals or videos which can explain in a simplified way
> the "potential" risk.. it could be useful for HR advocates?
>
> Hanane
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi all,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWFGZ8AAoJEAi1oPJjbWjpMtkH/3rzGnn+HU6loxQVknIkq/0j
> S0HNZ5HgIVRreONRauGxgnjrquRgDoWy6dGoedcr+0OlYZCsZrQ2oHdrvlZb/tzk
> asF6+hYFnCyx2sOlm3qRyEjifIb2NSuQqveKAgy2ofp5bLtui5+5O/XGwH7pi/hd
> 8Cs/SiXCV9eMqyNehQRM2cKDb21sR1aUbvwhzPOipDkikSQHopyEv/2N0TR37h1u
> VYpAPuANAFHOe6vfmBLZRyPofIhEok9SypUbIcK8wYFRDszVdUBNZ/QIBRw1O330
> aPbbLXPv6QbzXEVaw+JjkcTj5NLfpijP6ftw6AFzXgyejDcviC7jfDzd1HdF0Y0=
> =UaVp
> -----END PGP SIGNATURE-----
>

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 07 Oct 2015 11:25:40 +0200

Hi Hanane,

We're currently producing a film on the relation between Internet
protocols and Internet rights which will premiere at IETF94 in
Yokohama, and after that will be available online.

The film is based largely on interviews we did with the IETF community
at IETF92 in Dallas, but we're creating animations and adding other
content to make it a bit more attractive and digestible right now.

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 10/07/2015 10:14 AM, Hanane Boujemi wrote:
> Hi Niels,
> 
> I found the doc on DNS privacy consideration quite useful, do you
> have plans to produce visuals or videos which can explain in a
> simplified way the "potential" risk.. it could be useful for HR
> advocates?
> 
> Hanane
> 
> ----- Original Message ----- From: "Niels ten Oever"
> <[email-masked]> To: [email-masked] Sent: Wednesday, October 7,
> 2015 2:25:32 AM Subject: [hrpc] cases -> DNS
> 
> Hi all,
> 
> As laid out in our methodology, and discussed in Prague, we were
> going to document cases of in which protocols could strenghten or
> harm human rights (especially freedom of expression and/or freedom
> of assembly). We found two people ready to document cases in which
> protocols (potentially) strengthen or weaken human rights. Welcome
> on the list Will and Nex. After a discussion we decided to look
> into some of the following protocols: DNS [0], IP, VPN [1], HTTP,
> XMPP, TLS, mesh [2] and PPSPP [3].
> 
> Please find underneath the first draft by Will on DNS, all input
> is welcome of course. Tomorrow I will try to clean up the
> methodology draft as discussed and insert it in there. In the mean
> time all inputs, comments, questions and discussion points are very
> welcome!
> 
> Best,
> 
> Niels
> 
> [0] https://www.rfc-editor.org/rfc/rfc7626.txt [1]
> http://www.vpnc.org/vpn-standards.html [2]
> https://tools.ietf.org/html/rfc2973 [3]
> https://www.rfc-editor.org/rfc/rfc7574.txt
> 
> DNS =====
> 
> The Domain Name System (DNS), as specified in RFC 1035, acts as a
> core switchboard for the internet - associating human readable
> names with services. The DNS system operates a centralized core of
> ‘Root Resolvers’ , servers run by a set of organizations trusted by
> IANA to enact the organization’s decisions by accurately
> communicating which organizations have been delegated to manage
> registration under each Top Level Domain (TLD). Top Level domains
> are maintained and determined by IANA, and have evolved to
> encompass several classes of services. Some, like ‘.Com’ and
> ‘.Net’, provide a common space for expression of ideas, though
> their policies are enacted through US based countries. Other name
> spaces are delegated to specific nationalities, and may impose
> limits designed to focus speech in those forums both to promote
> speech from that nationality, and to comply with local limits on
> expression and social norms. Finally, the system has been recently
> expanded with the addition of “generic TLDs”, name spaces with
> accompanying regulations aimed to promote expression around
> specific topics, for instance ‘.travel’ and ‘.ninja’.
> 
> DNS has significant privacy issues, as described in RFC 7626.
> Notably amongst these, the protocol does not offer either
> encryption to limit the visibility of requests for domain
> resolution from several intermediary parties, nor does it offer
> authentication, allowing the client to know that they have received
> a correct, “authoritative”, answer to a query. Together, these
> decisions have resulted in ongoing harm to freedom of expression as
> the DNS protocol has become one of the central mechanisms used to
> block access to websites - limiting both the freedom of expression
> of the publisher to offer their content, and the freedom of
> assembly for clients to congregate in a shared virtual space.
> 
> There have been several mechanisms used impose these limitations
> based on the technical design of the DNS protocol. These have led
> to a number of situations where limits on expression have been
> imposed through subversion of the DNS protocol. Each of these
> situations has accompanying aspects of protocol design enabling
> those limitations.
> 
> Removal of records ----- There have been a number of cases where
> the records for a domain are removed from the name system due to
> real-world events. Examples of this removal include ‘seizure’ of
> names of illegally operating gambling operations by the United
> States ICE unit by compelling the US-based registrar in charge of
> the .com TLD to hand ownership of those domains over to the
> government. The same technique has been notably used by Libya to
> remove sites in violation of “our Country’s Law and Morality
> [which] do not allow any kind of pornography or its promotion.”
> 
> At a protocol level, the ability to seize domain names is enabled
> by the lack of transparency into DNS transfers, or any technical
> encoding of name ownership. Name ownership is purely a policy
> decision of registrars. While DNSSEC addresses distortion events
> described below, it does not tackle this problem, which is has the
> cooperation of (or compels) the registrar.
> 
> Documentation of this form of harm: [1]
> http://news.bbc.co.uk/2/hi/technology/7250916.stm [2] 
n-government/
> 
> Distortion of records ----- The most common mechanism by which the
> DNS system is abused to limit freedom of expression is through
> manipulation of protocol messages by the network. One form occurs
> at an organizational level, where client computers are instructed
> to use a local DNS resolver controlled by the organization. The DNS
> resolver will then selectively distort responses rather than
> request the authoritative lookup from the upstream system. The
> second form occurs through the use of deep packet inspection, where
> all DNS protocol messages are inspected by the network, and 
> At the national level, there are additional considerations. The
> most notable is the interactions between DNS distortion and
> internet routing. A study on collateral damage showed that the
> restrictions imposed by China on DNS responses in its network also
> affected the availability of sites to users in Germany, since some
> fraction of requests would transit through the Chinese network,
> even though none of the participants were located there.
> 
> A notable instance of distortion has occurred in Greece [3], where
> a study found evidence of both of deep packet inspection to distort
> DNS replies, and overblocking of content, where ISPs prevented
> clients from resolving the names of domains which they were not
> instructed to do through the governmental order prompting the
> blocking systems there.
> 
> possible by a lack of authentication in the DNS protocol. The
> DNSSEC protocol is not widely in use, but provides an extension
> allowing the client to know that a response is ‘Authoritative’ -
> that it has been generated by the server which has technical
> ownership of the name requested. Even still, there are a range of
> downgrade attacks, where a client may continue to follow the
> resolution of an injected message without such a signature, since
> it may not know that it should expect the response to be signed.
> Selective distortion of records has also been made possible by the
> predictable structure of DNS messages, which make it
> computationally easy for a network device to watch all passing 
> messages even at high speeds, and the lack of encryption, which
> allows the network to distort only an objectionable subset of
> protocol messages .
> 
> Documentation of this form of harm: [1]
> http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf 
> [2]
> http://policyreview.info/articles/analysis/internet-censorship-turke
>
> 
y
ris-update.pdf
> Injection of records ----- Responding incorrectly to requests for
> name lookups is the most common mechanism that in-network devices
> use to limit the ability of end users to discover services. A
> deviation which accomplishes a similar objective, though may be
> seen as different from a freedom of expression perspective, is the
> injection of incorrect responses to queries.  The most prominent
> example of this behavior occurs in China, where requests for
> lookups of sites which have been deemed inappropriate will trigger
> the network to respond with a bogus response, causing the client to
> ignore the real response when it subsequently arrives. Unlike the
> other forms of discussion discussed above, injection does not
> stifle the ability of a server to announce it’s name, it instead
> provides another voice which answers sooner. This is effective
> because of the DNS protocol’s decision to provide whatever answer
> it receives first, and stop listening for subsequent answers, and
> enabled by the lack of authentication or encryption in the
> protocol.
> 
> Documentation of this form of harm: [1] 
df
> 
> 
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Oct 2015 12:01:53 +0200

> Please find underneath the first draft by Will on DNS,

> The DNS system operates a centralized core of ‘Root Resolvers’ ,

Please pay attention to the terminology. There is no such thing as a
root resolver. This was probably a reference to root servers. Also,
the adjective "centralized" seems strange here.

> servers run by a set of organizations trusted by IANA

Precisely not (this is one of the darkest secrets of Intenet
governance). The root server operators existed long before ICANN, the
vast majority of them have zero relationshiop with ICANN and there is
no ICANN process to add or remove a root server.

> Top Level domains are maintained and determined by IANA,

Add "acting as a delegate of the US governement"

> nor does it offer authentication, allowing the client to know that
> they have received a correct, “authoritative”, answer to a query.

This is untrue, because of DNSSEC (which is mentioned later but
ignored in this sentence).

> the US-based registrar in charge of the .com TLD

Registry not registrar.

> the lack of transparency into DNS transfers,

I do not see what is the "lack of transparency into DNS transfers".

> or any technical encoding of name ownership.

Is it a reference to alternative techniques like proving name
ownership through cryptographic signatures plus a public record, such
as Namecoin? If so, it could be explained more clearly.

> protocol is not widely in use, but provides an extension allowing
> the client to know that a response is ‘Authoritative’ - that it has
> been generated by the server which has technical ownership of the
> name requested.

Self contradictory sentence: either DNSSEC exists or it doesn't. If it
exists (which is the case), there *is* "authentication in the DNS
protocol".

> Even still, there are a range of downgrade attacks, where a client
> may continue to follow the resolution of an injected message without
> such a signature, since it may not know that it should expect the
> response to be signed.

Either there is a technical weakness in DNSSEC, allowing this attack,
and it must be published, to allow IETF to patch the DNSSEC protocol
(or to drop it), or this is pure FUD (I have no idea of where does
this sentence come from).

Technical note: the DNS client knows that "it should expect the
response to be signed" through the DS (Delegation Signed)
records. When there is really no DS, the client knows it through
"secure denial of existence", thanks to NSEC and NSEC records.

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 07 Oct 2015 12:53:41 +0200

Thanks a lot for these comments Stephane.

On 10/07/2015 12:01 PM, Stephane Bortzmeyer wrote:
> Please pay attention to the terminology. There is no such thing as
> a root resolver. This was probably a reference to root servers.
> Also, the adjective "centralized" seems strange here.

Agree. This is where we will need to get into a precise description of
what centralized and distributed means.

> governance). The root server operators existed long before ICANN,
> the vast majority of them have zero relationshiop with ICANN and
> there is no ICANN process to add or remove a root server.
> 

This would be really interesting to dig out and describe more
precisely. You got some more info, links or guidance here Stephane, or
do we need to dig up 'Ruling the Root' by Milton Mueller?

> Add "acting as a delegate of the US governement"

"..even though there is currently a process ongoing to transfer this
authority to the global Internet community."

>> nor does it offer authentication, allowing the client to know
>> that they have received a correct, “authoritative”, answer to a
>> query.
> 
>> by the lack of transparency into DNS transfers,
> 
> ownership through cryptographic signatures plus a public record,
> such as Namecoin? If so, it could be explained more clearly.
> 
>> ownership of the name requested.
> 
> Self contradictory sentence: either DNSSEC exists or it doesn't. If
> it exists (which is the case), there *is* "authentication in the
> DNS protocol".
> 

+1. Let's make a real clear differentiation here between what is often
implemented and what is in the protocol. I think here were should
solely focus on the protocol.

>> Even still, there are a range of downgrade attacks, where a
>> client may continue to follow the resolution of an injected
>> message without such a signature, since it may not know that it
>> should expect the response to be signed.
> 
> Either there is a technical weakness in DNSSEC, allowing this
> attack, and it must be published, to allow IETF to patch the DNSSEC
> protocol (or to drop it), or this is pure FUD (I have no idea of
> where does this sentence come from).
> 
> response to be signed" through the DS (Delegation Signed) records.
> When there is really no DS, the client knows it through "secure
> denial of existence", thanks to NSEC and NSEC records.
> 

Thanks again Stephane, really useful. Are there any other
vulnerabilities you think that should be mentioned?

Best,

Niels

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Oct 2015 13:12:44 +0200

On Wed, Oct 07, 2015 at 12:53:41PM +0200,
 Niels ten Oever <[email-masked]> wrote 
 a message of 113 lines which said:

> precisely. You got some more info, links or guidance here Stephane,
> or do we need to dig up 'Ruling the Root' by Milton Mueller?

I'm afraid (from my memory) that Mueller's book does not mention the
management of the root name servers. As I said, it is one of the best
kept secrets of Internet governance. The professionals of the
governance circus typically ignore this issue (too practical? too
difficult?).

> authority to the global Internet community."

And "Santa will give presents to nice kids at Christmas", yes.

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 07 Oct 2015 13:46:42 +0200

On 10/07/2015 01:12 PM, Stephane Bortzmeyer wrote:
> On Wed, Oct 07, 2015 at 12:53:41PM +0200, Niels ten Oever
> <[email-masked]> wrote a message of 113 lines which said:
> 
>>> governance). The root server operators existed long before
>>> ICANN, the vast majority of them have zero relationshiop with
>>> ICANN and there is no ICANN process to add or remove a root
>>> server.
>> 
>> precisely. You got some more info, links or guidance here
>> Stephane, or do we need to dig up 'Ruling the Root' by Milton
>> Mueller?
> 
> I'm afraid (from my memory) that Mueller's book does not mention
> the management of the root name servers. As I said, it is one of
> the best kept secrets of Internet governance. The professionals of
> the governance circus typically ignore this issue (too practical?
> too difficult?).
> 

This is how I understand it, but please correct me if I'm wrong (also
looping in Patrik here):

ICANN, under the IANA function, manages the IANA database. If changes
are made, changes are subsequently checked by the NTIA. The actual
changes are then made by Verisign (who have a direct contract with
NTIA [0]) in the a-root. And the other 12 roots then federate from the
a-root.

I think this is regularly described as a hierarchical distributed
system. (This definition could help us stay away from the discussion
whether this is centralized or not).

Question from my side: were there ever any discrepancies between the
root servers, other than those caused by a time lag?

>> "..even though there is currently a process ongoing to transfer
>> this authority to the global Internet community."
> 

Stop destroying dreams, Stephane. Hope dies last ;)

But since the process is ongoing, it would be good to mention. Let's
stick to the facts, no?

Best,

Niels

[0] http://www.ntia.doc.gov/page/verisign-cooperative-agreement

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Oct 2015 10:03:24 -0400

Hi,

On Wed, Oct 07, 2015 at 02:25:32AM +0200, Niels ten Oever wrote:

> services.

This is part of what the DNS does, it's true.  But the more accurate
depiction is that this is an important but not only job of the DNS.
The DNS is also used, for instance, in various service discovery
systems.  It can also be used as a rather nice way to improve user
security by allowing use of strong cryptography without dependence on
Certificate Authorities.  

> The DNS system operates a centralized core of ‘Root
> Top Level Domain (TLD).

Apart from the corrections Stephane sent, I think it's important to
recognise that the DNS is not at all centralized.  The DNS is arguably
the most successful distributed database system ever built or
operated.  It is decentralized in two ways.  First, the authority in
the system is decentralized.  When you get a domain name delegated to
you, nothing about your operation of that is thereafter controlled (in
a technical sense) _except_ the delegation.  It's true your parent can
remove the delegation, but that's all they can do.  Second, it's also
decentralized in operation, by virtue of caches theoretically governed
by the Time To Live setting established by the zone operator.  It's
really radically decentralized.

It's also worth noting tht the root servers are the root servers
because they're the ones everyone uses.  You can change this on your
own resolver, if you want, by changing the root.hints file you use.
Of course, if people start using various different roots, and they're
not operating a single namespace, then we no longer have one Internet,
but multiple.  That's a risk of "multiple roots".

> Top Level domains are maintained and

It would be nice to draw a distinction here, because this point has
caused a lot of trouble in the IANA transition this year.  ICANN has
two roles.  IANA today (historically less so) is mostly a clerical
job.  So it's strictly true that IANA places the TLDs in the root
zone, but it does so according to policy decisions made by ICANN in
its policy-making function, and not in its IANA function.

> and have evolved to encompass several classes of
> based countries.

The basic idea that gTLDs have any particular function is fetching but
no longer really true.  I don't know what a "US-based country" is, but
maybe that means "company".  It's true that many of the organizations
operating gTLDs are US-based, but not all.  For instance, Afilias
operates info and is incorporated in Ireland.

> has been recently expanded with the addition of “generic TLDs”, name

The addition of gTLDs is not a recent expansion: that's what com and
net are too.  Perhaps "recently expanded with additional generic TLDs".

> around specific topics, for instance ‘.travel’ and ‘.ninja’.

No, the ones that have specific topics are sometimes called "sponsored
TLDs", but the ICANN-level policy difference is at best minimal.  The
operator of any domain can make policies about what may be registered
in it, and that's how the new scope-limited gTLDs are working: they
adopt rules about who may register or what those registrations may be
used for.  Many of the new gTLDs have no different policies than com
or net or org.

> answer to a query.

Authentication is offered by DNSSEC, which is now enjoying some modest
deployment success, so that seems not too relevant.

> the central mechanisms used to block access to websites - limiting

I think I'd say, "interference with the operation of the DNS has
become one of the …".

> Law and Morality [which] do not allow any kind of pornography or its

The DNS mechanism here is simply the ability to remove a delegation.
That is the sole technical function that is invoked, and it's an
administrative decision (i.e. actually a policy decision) imposed by
the technical means of removal of the delegation.  In the presence of
DNSSEC, the delegation cannot be undetectably blocked by a third
party.  While it is true that detectably blocking something can
suppress speech, it does so in the same way that redaction via black
lines over text does: the reader can tell.  

> of name ownership.

This is external to the DNS, but it's not the case that there is no
such transparency.  That's what whois gets you.  The whois (and we
hope its replacement by RDAP) provides the view you're looking for.

> Name ownership is purely a policy decision of
> registrars.

Yes.

> of the participants were located there.

I think this part is conflating issues and doesn't belong here.

> requested.

As I note above, DNSSEC should be reflected earlier.  Moreover, one
can hardly claim a weakness on the grounds that people aren't using
the technology available.

> the response to be signed.

If it does not know that, it hasn't performed validation.  It is never
possible under DNSSEC not to know that the response should be signed
unless one is not validating or the name is not properly signed.

> answers, and enabled by the lack of authentication or encryption in

No, injection also won't work in the face of DNSSEC, either.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: seamus tuohy <[email-masked]>
Date: Wed, 7 Oct 2015 13:55:50 -0400

> solely focus on the protocol.

If the focus is solely on the current protocol then it would seem there
is no use to go into any of the social or political flaws in the current
root server or name server structure and organization. I would posit
that the motivations behind the creation of RFC 4033 are very relevant
to this discussion. A simple enumeration of the current flaws or
benefits within these documents would ignore the rich history of the
IETF responding to perceived flaws that have, or will lead to human
rights violations. I am sure there is far more context to be found in
the archive of the 4033 email list that may directly talk to the
incidents that inspired its creation, but the first draft included a
threat model section that exposes some of context.

"Threat Model

   The Domain Name System (DNS) protocol has been the target of several
   well-publicized attacks since it's creation.  These attacks are
   centered on altering DNS traffic in transit, or sending erroneous
   referral messages to caching servers (i.e. "cache poisoning").   The
   result of these attacks are traffic redirection or complete "zone
   hijacking" if the malicious referral code is allowed to propagate."

The "well-publicized attacks" that spawned the creation of DNSSEC hint
at how wide scale human-rights abuses have, and should, be taken into
consideration in the creation and revision of Internet protocols. I
think the history of protocols that have changed, possibly because of
human rights concerns, are as important as their current possible
ability to harm/strengthen human rights because it provides us concrete
protocol issues that have been addressed in the past, and a glimpse at
how protocol level changes can be made to directly respond to flawed
social or political structures and abuses.

> iQEcBAEBCAAGBQJWFPm0AAoJEAi1oPJjbWjplR8H/RFPOPxgV85eDwTkmlWEtqyi
> mq0TeaL2JHWVhq8ve6TkXcSEMwFaNHkoouCgMo3GTxsJzjNhgvcDGfmQnB1SECqg
> Qh0db33pzJlECXa7IBYp2MLP1myV/Ru7nX58CY/lAPJMuwHdKLCjiTtFC9nUHDI7
> Gr16HF4/B1CAN1oGh2ozqhlTUkmsVxAC8zshXHo+zmSHlgCFxNqwVIcl7ZNwGHuL
> kCIWM6Ap2aT1+VIcqH1g8FJKtyXVdJczoMpd6QNEaSKjjJ2XP4C22pMa5cyFPMnP
> 9F6HkkoXpCWSadPxBn+8+rvWLuy6IP7s0rFAVXw7oFNrXp0k5CxP/1s4EwOAO9s=
> =Jf05

--
seamus tuohy | Sr. Technologist - Internet Initiatives
[email-masked]
Skype/XMPP on request
PGP: D9F9 B306 4FDF 373D 1025 4313 2CF2 3545 F2D7 DAC4
MiniLock: 2G3JmRWRYB3B7rthZqkzomcRe8GwJvPtSooA748XMsTBdf

INTERNEWS | Local Voices. Global Change.
www.internews.org | @internews

---

From: Avri Doria <[email-masked]>
Date: Sat, 10 Oct 2015 09:52:28 -0400

On 07-Oct-15 07:12, Stephane Bortzmeyer wrote:
>  As I said, it is one of the best

I am not sure it is either a secret of has always been ignored.  I
remember it being discussed as far back as the working Group on Internet
Goverance (WGIG) in 2005. The WGIG Report says the following:
> Lack of formal relationship with root server operators.
> • The root zone operators perform their functions today without a
> formal relationship with any authority.

The WGIG Background report also contains a discussion, though not as
explicit as yours. There have been other references over the years in
various Internet Governance Forum (IGF) and other discussions.

Over the years there have been many discussions in the various Internet
governance venues of the fact that root server operators are each
independent operators,  who do what they do based on their own decisions
with loose informal coordination among themselves. This notion of
informal coordination is central to much of the technical management of
the Internet.  There are those who have wanted to find a way to add
international governance to that, but up to now that has remained a non
starter. As you say, it may be too difficult.

There have also been some discussions over the years questioning whether
DNSSEC in some sense bound these root server a bit more as it removed
some of their  discretion about which records they accepted, providing a
technical measure of coordination.

I am not making a normative statement at this point about whether this
independence and the DNSSEC are helpful or not to freedom of expression
and association, but just trying to argue that is not quite as  deep and
dark a secret among the 'circus' professionals as presented.  I do agree
that getting Internet governance of the root server operators does not
seem to be a current work item - root servers are not even mentioned in
the early drafts of  WSIS+10 paper the UN General Assembly will be
approving at the end of the year.  I am also sure that many of the
participants in Internet governance know nothing about this, but it
isn't a dark secret and it has been discussed over the years.

avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Will Scott <[email-masked]>
Date: Sat, 10 Oct 2015 09:53:50 -0700

Thanks for all the feedback. I'm working through updating the the first
draft, and will drop root server discussion and will do some more diligence
at living in our modern dnssec world.

Injection of records, as in the case of China, does seem to be one of the
major attacks that the protocol has historically (and in practice
continues) to be vulnerable to; despite being mitigated by DNSSEC.  I'd be
interested in input in how that might be most effectively framed. Andrew
seems to suggest the injection section is hard to justify from the
protocol, and hurts the argument. Is there consensus that it should be
dropped?

--Will

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Oct 2015 12:21:49 +0200

On Wed, Oct 07, 2015 at 01:46:42PM +0200,
 Niels ten Oever <[email-masked]> wrote 
 a message of 71 lines which said:

> This is how I understand it,

You talk about the management of the root database, I was talking
about the management of root name servers, it's very different (for
instance, ICANN has a role in the first one, not in the second).

> root servers, other than those caused by a time lag?

http://masonlee.org/2009/12/18/dns-takeover-1998/

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 12 Oct 2015 14:12:39 +0200

Hi Will,

Since it is the most prevalent attack, I do not think it should be
dropped, but it should be shown this is mitigated by the use of
DNSSEC. However DNSSEC is not mandatory, so the the protocol still
allows for this vulnerability imho.

Best,

Niels

Niels ten Oever
Head of Digital

Article 19
www.article19.org

On 10/10/2015 06:53 PM, Will Scott wrote:
> Thanks for all the feedback. I'm working through updating the the
> first draft, and will drop root server discussion and will do some
> more diligence at living in our modern dnssec world.
> 
> Injection of records, as in the case of China, does seem to be one
> of the major attacks that the protocol has historically (and in
> practice continues) to be vulnerable to; despite being mitigated by
> DNSSEC.  I'd be interested in input in how that might be most
> effectively framed. Andrew seems to suggest the injection section
> is hard to justify from the protocol, and hurts the argument. Is
> there consensus that it should be dropped?
> 
> --Will
> 
> 
> On Sat, Oct 10, 2015 at 6:52 AM, Avri Doria <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>> As I said, it is one of the best kept secrets of Internet
>> governance. The professionals of the governance circus typically
>> ignore this issue (too practical? too difficult?).
> 
> remember it being discussed as far back as the working Group on
> Internet Goverance (WGIG) in 2005. The WGIG Report says the
> following:
>> Lack of formal relationship with root server operators. • The
>> root zone operators perform their functions today without a 
> The WGIG Background report also contains a discussion, though not
> as explicit as yours. There have been other references over the
> years in various Internet Governance Forum (IGF) and other
> discussions.
> 
> Over the years there have been many discussions in the various
> Internet governance venues of the fact that root server operators
> are each independent operators,  who do what they do based on their
> own decisions with loose informal coordination among themselves.
> This notion of informal coordination is central to much of the
> technical management of the Internet.  There are those who have
> wanted to find a way to add international governance to that, but
> up to now that has remained a non starter. As you say, it may be
> too difficult.
> 
> There have also been some discussions over the years questioning
> whether DNSSEC in some sense bound these root server a bit more as
> it removed some of their  discretion about which records they
> accepted, providing a technical measure of coordination.
> 
> I am not making a normative statement at this point about whether
> this independence and the DNSSEC are helpful or not to freedom of
> expression and association, but just trying to argue that is not
> quite as  deep and dark a secret among the 'circus' professionals
> as presented.  I do agree that getting Internet governance of the
> root server operators does not seem to be a current work item -
> root servers are not even mentioned in the early drafts of  WSIS+10
> paper the UN General Assembly will be approving at the end of the
> year.  I am also sure that many of the participants in Internet
> governance know nothing about this, but it isn't a dark secret and
> it has been discussed over the years.
> 
> avri
> 
> 
> 
> 
> 
> 
> 
> --- This email has been checked for viruses by Avast antivirus
> software. https://www.avast.com/antivirus
> 
> [email-masked] <mailto:[email-masked]>

---

From: Will Scott <[email-masked]>
Date: Thu, 15 Oct 2015 02:35:44 -0700

Thanks for the great set of comments.  I've tried to incorporate them into
a second draft:

https://github.com/willscott/IRTF-HRPC/commit/808c9b57bbf50e6ba3c717e73445a8ef8f97991b

As before, feedback is welcome.
One point I haven't included that might be worth including is a discussion
of name minimization. In the initial DNS implementation, and continuing in
many resolvers, the requests to the root server and tld server include the
full requested name.  This has resulted in passive surveillance of those
high-traffic servers.

On Mon, Oct 12, 2015 at 5:12 AM, Niels ten Oever <[email-masked]>
wrote:

> iQEcBAEBCAAGBQJWG6O3AAoJEAi1oPJjbWjpiXIH/0vonZjISozLnUa9Q5cocpo6
> EGzmv2AWWsjhe34URPgh5DRvs9Yp9XI1DDbHbLihGUtfBhLsYXLOSU5Y5z0pAoDc
> JnQffhaWLUZgTIJPGQcqGbeKCTsudhsPcWnnu94XV2iSpysAOJyEphgnjrxWejoV
> qHkyLwgSb+Vcx54R25e0gc8IJ0g4PvHf/tIHkx/3oxrG7LpQ+M4VOwz/FA/E72De
> zpu4eEMQ4BRXbb7GkniR9qPip1eCCvb/HY9LD8SIZvXglRePTlEda9Ww3+92S60S
> 75lDfKrIw63weu3w5E+wDZgMVScOZ857yY+hCXNZ9l+2Sx/5cKslIY49I+WXMN0=
> =UUS6