-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Since Alec Muffett seems to have better things to do, I feel obligated
to do what he should have done before publishing his draft: comparing
the IANA Considerations for .onion in the
draft-grothoff-iesg-special-use-p2p-names-04 (P2PNames) and
draft-appelbaum-dnsop-onion-tld-01 (OnionTLD).
# OVERVIEW
draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the
processing of .onion special-use TLD, as the P2PNames draft was
considered too controversial (and maybe too complicated?). But this
work, although sporting the name of a co-author of the P2PNames draft
and claiming support by the Tor Project community, did not benefit
neither from concerted action with, nor consideration for the existing w
ork.
A simple comparison of the IANA Considerations for the P2PNames and the
OnionTLD drafts highlights critical flaws in the OnionTLD draft that
curiously didn't receive any attention at all so far (except my own, but
I reserved my comments up until now for others to come up with this, in
vain.)
I noticed 3 major issues in the OnionTLD draft:
1. the users considerations pretend that users must use onion-aware
software in order to access Onionspace, but I assert that you and I can
use an ordinary Web browser, type in a .onion address, and access the
requested service. Not only OnionTLD conflicts with P2PNames on that
point, it also confuses users' awareness and application software
responsibility (and possibly the scope of IANA Considerations' first
question).
2. more importantly, where P2PNames imposes NXDOMAIN response to
authoritative name servers, OnionTLD makes it a soft requirement, thus
leaving the possibility for name servers to hijack Onionspace without
user consent nor awareness.
3. this error is confirmed for DNS server operators, where OnionTLD
makes it a soft requirement not to override responses.
Given the complementarity of 2. and 3. for successful dragnet abuse, I
have difficulty believing in a coincidence, and am very concerned that
such points could go through an IETF process without an itch.
That the P2PNames draft remains controversial should not remove from its
qualities, and notably its technical fitness and attention to detail.
As the editor of this draft, I apologize for the shameless
self-promotion and urge the DNSOP WG members to not confuse diligence
and precipitation.
# IANA CONSIDERATIONS DETAILS
This verbose section details point by point the differences and put them
in context with RFC6761 questionnaire.
## 1. Users
- From RFC6761: "Are human users expected to recognize these names as
special and use them differently? In what way?"
*
The OnionTLD interpretation is wrong. I want for proof that I can
browse Onionspace with an ordinary Web browser that does not treat
.onion sites any differently from a .org or a .net. The OnionTLD
interpretation also contradicts the P2PNames interpretation, and pushes
responsibility to the users (who should know what they're doing).
Moreover, the OnionTLD interpretation also says that onion addresses are
"only available through [onion-aware] software", which is not the case.
*
P2PNames says: "Users can use these names as they would other domain
names, entering them anywhere that they would otherwise enter a
conventional DNS domain name.
Since there is no central authority necessary or possible for assigning
.onion names, and those names correspond to cryptographic keys, users
need to be aware that they do not belong to regular DNS, but are still
global in their scope."
OnionTLD contradicts this: "Users: human users are expected to recognize
.onion names as having different security properties, and also being
only available through software that is aware of onion addresses."
## 2. Application Software
- From RFC6761: "Are writers of application software expected to make
their software recognize these names as special and treat them
differently? In what way? (For example, if a human user enters such a
name, should the application software reject it with an error message?)"
*
The OnionTLD interpretation only covers the case of onion-aware
applications, and then do not specify the response.
*
P2PNames says: "Application software MAY recognize .onion domains as
special, and SHOULD use these names as they would other domain names.
Application software MAY implement mechanisms helping the user to ensure
their privacy expectations are met, such as warning the user if they do
not detect an active local Tor resolver, displaying a warning on
first-use of an .onion domain to explain the necessity of a Tor resolver
to reach such domains, etc.
If an application knows how to differenciate between DNS and P2P name
resolution, it:
* SHOULD NOT pass requests for .onion domains to DNS resolvers
or libraries,
* MUST expect NXDOMAIN as the only valid DNS response, and
* SHOULD treat other answers from DNS as errors.
Tor-aware applications MAY also use Tor resolvers directly."
OnionTLD says: "Application Software: Applications that implement the
Tor protocol MUST recognize .onion names as special by either accessing
them directly, or using a proxy (e.g., SOCKS [RFC1928]) to do so.
Applications that do not implement the Tor protocol SHOULD generate an
error upon the use of .onion, and SHOULD NOT perform a DNS lookup."
## 3. Name Resolution APIs and Libraries
RFC6761 says: "Are writers of name resolution APIs and libraries
expected to make their software recognize these names as special and
treat them differently? If so, how?"
*
Here comes a good mark to OnionTLD: it's more precise than the P2PNames
draft on this point, imposing a MUST on resolution vs. NXDOMAIN. The
P2PNames authors preferred not making any difference there between
onion-aware applications and not.
*
P2PNames says: "Name resolution APIs and libraries SHOULD either respond
to requests for .onion names by resolving them via the Tor protocol, or
respond with NXDOMAIN."
OnionTLD says: "Name Resolution APIs and Libraries: Resolvers that
implement the Tor protocol MUST either respond to requests for .onion
names by resolving them (see [tor-rendezvous]) or by responding with
NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN."
## 4. Caching DNS Servers
RFC6761 says: "Are developers of caching domain name servers expected to
make their implementations recognize these names as special and treat
them differently? If so, how?"
*
In P2PNames, "immediate negative responses" is not specified yet (for
lack of discussion about it across domain names) as negative responses
might be different than NXDOMAIN in some case (e.g. for .gnu domains).
*
P2PNames says: "Caching DNS servers SHOULD recognize .onion names as
special and SHOULD NOT attempt to look up NS records for them, or
otherwise query authoritative DNS servers in an attempt to resolve
.onion names. Instead, caching DNS servers SHOULD generate immediate
negative responses for all such queries."
OnionTLD says: "Caching DNS Servers: Caching servers SHOULD NOT attempt
to look up records for .onion names. They SHOULD generate NXDOMAIN for
all such queries."
## 5. Authoritative DNS Servers
RFC6761 says: "Are developers of authoritative domain name servers
expected to make their implementations recognize these names as special
and treat them differently? If so, how?"
*
This is the main conflicting point: OnionTLD does not recognize .onion
as special and allows Authoritative DNS servers to respond for .onion
("SHOULD"). From the P2PNames perspective, this is unacceptable, and a
complete failure to address the privacy concerns set forth by the draft.
If OnionTLD would be accepted in that form, it would allow the root
servers to capture leaked onion requests AND RESPOND POSITIVELY FOR THEM
!
*
P2PNames says: "Authoritative DNS servers are not expected to treat
.onion domain requests specially. In practice, they MUST answer with
NXDOMAIN, as "ONION" is not available via global DNS resolution, and not
doing so MAY put users' privacy at risk (see item 6)."
OnionTLD says: "Authoritative DNS Servers: Authoritative servers SHOULD
respond to queries for .onion with NXDOMAIN."
## 6. DNS Server Operators
RFC6761 says: "Does this reserved Special-Use Domain Name have any
potential impact on DNS server operators? If they try to configure
their authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid? Do DNS server
operators need to know about that and understand why? Even if the name
server software doesn't prevent them from using this reserved name, are
there other ways that it may not work as expected, of which the DNS
server operator should be aware?"
*
Again, the OnionTLD authorizes normal use of .onion in the DNS, which is
totally out of the question and conflicts with the purpose of the
P2PNames draft to protect users' privacy.
*
P2PNames says: "DNS server operators SHOULD be aware that .onion names
are reserved for use with Tor, and MUST NOT override their resolution
(e.g., to redirect users to another service or error information)."
OnionTLD: "DNS Server Operators: Operators SHOULD NOT configure an
authoritative DNS server to answer queries for .onion. If they do so,
client software is likely to ignore any results (see above)."
## 7. DNS Registries/Registrars
RFC6761 says: "How should DNS Registries/Registrars treat requests to
register this reserved domain name? Should such requests be denied?
Should such requests be allowed, but only to a specially-designated
entity? (For example, the name "www.example.org" is reserved for
documentation examples and is not available for registration; however,
the name is in fact registered; and there is even a web site at that
name, which states circularly that the name is reserved for use in
documentation and cannot be registered!)"
*
Yet another example of the difference between documentation and command:
P2PNames explains why it is so, while OnionTLD simply states it without
any context.
*
P2PNames says: "DNS registries/registrars MUST NOT grant any request to
register .onion names. This helps avoid conflicts [SAC45]. These names
are defined the Tor protocol specification [TOR-PROTOCOL], and they fall
outside the set of names available for allocation by registries/registra
rs."
OnionTLD: "DNS Registries/Registrars: Registrars MUST NOT register
.onion names; all such requests MUST be denied."
# CONCLUSION
Until now the debate has been in opposition to a single P2PNames draft
covering more than one domain, and this argument mostly suspended actual
criticism of the contents of the draft itself. I would like that this
comparison bring forward another process to consider the P2PNames draft:
instead of focusing on how it should be (split), attention should be put
on what is good (or wrong) with each treated domain, so that
collaborative work is not stuck on beliefs and political arrangements,
but keeps the technical merits first and foremost.
I firmly believe that even in the event of splitting the P2PNames draft,
various RFCs covering the P2PNames should belong to a single family of
publications, maybe with one Informational RFC covering all of the
pTLDs, and one or more pTLDs per Special-Use Domain Names reservations
to keep reading simple to digest for administrative entities who do not
need to delve into the technical details. Whether we split the P2PNames
draft or not, I think that 1) further work on these domains SHOULD be
collaborative and not competitive; 2) the Peer-to-Peer systems form a
single logical entity that should be addressed as such.
I'm looking forward to break this opportunistic behavior to play
politics and satisfy administrative formalities, and instead use the
precious resources of our brains to constructive dialog towards rough
consensus on privacy matters. I dearly miss the (volunteer) time I had
to spend on making this document available.
==
hk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQJ8BAEBCgBmBQJVURvSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9U8kP/163QkTpBN5LJpg6eBTQMEGN
J9cbG+rPwspvU/VJoQoKhVbPMxoJMdPsziMUvlMT+4uZ3RdtxKdBusQxrie20DK6
9vnGMaIpoHA/64bPtL9qpUB1OU8O05LVSZfNibfiQPSYaAubut321cNH+BDb5IUw
ktno8YfVh38rTk/+cnvLHDxHWWHuSrlsXlkFjvVe4dvZ4wNtuUVhO24I7zCv+WXR
3ECCug3+SCO6fkAo636htX0aPX4kyV4uv63riQ3nNlFLrwQgHXbqJQOEM8xTe8t4
IzXj2jz+bjnrHf92qNHJqkr5fnyOpM8BNlET5MwTgrPDswLaYmuo9hUd5V3cA4HU
GeCVG/YI3jeqLLH/j4XcfyfAdeZBTrTSIepTSPIr1x+PX1gXaygeh1QXcnK5GRAx
OVJW+cDCvVh+pQ7/EuN7g3WpW9encevbiw1OwBBBiTp5g+eq3nVEQG9o1w2r+tSi
MBFDiA1DPVgxkT1t1+R8GCAbCMe6o8FcR9yGr8xqKE2Ey3ygJTmb3VebrfVaM0FK
oi1P/pn66JO9alOJS25pz9b1e0RwVF3d6gBsVh6PD77osvOIb5ew4Hh1psqh7nXk
ZahgfsRoYwF6kKQfrPdwaQFI4yx0r8q5qLv80bluRJVvnd0iSlXfWyz5emYz/dPr
LWt1LTuFs0IRrfQoAM31
=bkT8
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
