On Tue, Jul 14, 2015 at 12:24:38PM -0700, The IESG wrote:
>
> The IESG has received a request from the Domain Name System Operations WG
> (dnsop) to consider the following document:
> - 'The .onion Special-Use Domain Name'
> <draft-ietf-dnsop-onion-tld-00.txt> as Proposed Standard
I object to the publication of the above draft as Proposed Standard.
The intended registration is incompatible with the registration policy
laid out in RFC 6761 and is likely to create a false sense of security.
RFC 6761 requires a "Standards Action" or "IESG Approval" as per RFC 5226.
RFC 5226 states (page 11)
IESG Approval is not intended to be used often or as a
"common case"; indeed, it has seldom been used in practice
during the period RFC 2434 was in effect. Rather, it is
intended to be available in conjunction with other policies
as a fall-back mechanism in the case where one of the other
allowable approval mechanisms cannot be employed in a timely
fashion or for some other compelling reason. IESG Approval
is not intended to circumvent the public review processes
implied by other policies that could have been employed for
a particular assignment. IESG Approval would be
appropriate, however, in cases where expediency is desired
and there is strong consensus for making the assignment
(e.g., WG consensus).
It is unclear what path is suggested by the IESG since the draft, other than
RFC 6762 for the "local." TLD, does not contain a protocol specification.
It does not even contain a normative reference to such protocol specification.
An "Applicability Statement" might be possible, but details ought to have been
specified in the Last Call.
It is my reading that any protocol eligible for a registration in the "Special
Names" registry has to be an IETF Standards Track protocol - the grandfathered
entries in that very registry nonwithstanding. Any deliberations w.r.t. the
Tor protocol are missing from the above draft and the Last Call message.
The response to question 2 (of 7) says
2. Application Software: Applications (including proxies) 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.
RFC 6762 says
2. Application software may use these names as they would other
similar DNS names, and is not required to recognize the names
and treat them specially. Due to the relative ease of spoofing
dot-local names, end-to-end cryptographic security remains
important when communicating across a local network, just as it
is when communicating across the global Internet.
The "Special Names" registry does not offer any means to convey any particular
behaviour, let alone differences between various reserved names. It is more
than brave to expect that non-supporting implementations would be able (or
willing) to follow the SHOULDs in the first quoted block.
The response to question 3 (of 7) reads
3. Name Resolution APIs and Libraries: Resolvers MUST either either
respond to requests for .onion names by resolving them according
to [tor-rendezvous] or by responding with NXDOMAIN.
The first half of the "MUST" refers to an informative reference of unknown status
without any explanation for a "downref".
Response 4 reads
4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look
up records for .onion names. They MUST generate NXDOMAIN for all
such queries.
It remains to be specified how these "generated" responses would interact
with DNSSEC validation. Again, it is unclear how agnostic (as of today)
recursive resolvers would learn about the new name and apply specific behaviour to it.
Response 5
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
does not specify what zone the targetted "Authoritative DNS Servers" are
supposed to be authoritative for. Root name servers will respond NXDOMAIN
as long as onion. will not have been delegated and other servers would
usually respond with REFUSED. This is probably no different from normal
DNS modus operandi and thus would not need a particular description.
The draft does not explain why it asks for a "special name" at the top level.
Neither the draft nor the Last Call document or envision any coordination
with the responsible body as per the MoU RFC 2860.
I am sorry to say that while the protocol inquestion has all my sympathy,
the request put forward fails to meet the registration criteria. However,
it identifies several points in RFC 6761 that would benefit from clarification,
first and foremost the role of the "seven responses", their (retroactive) applicability
to otherwise agnostic implementations and the communication of details towards
potentially cooperating implementations.
-Peter