Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

From: Jacob Appelbaum <[email-masked]>
Date: Mon, 16 Mar 2015 22:16:37 +0000

Hi,

I realized after uploading that I hadn't sent this along for discussion.

Hopefully it is a topic of discussion in Dallas.  Tor's onion names
are widely deployed and used by lots of folks all around the world.
Our deployment size isn't news or really much of a discussion point -
rather, I'm primarily concerned about users who have certificates
issued to .onion names. Our Special Use Domain Name for consideration
is directly related to things happening in the CAB forum. The CAB
Forum context is here:
https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
- most importantly is the date October 1st. On that date we'll have a
death day for currently issued certifcates with .onion names. This
makes the onion name issue rather time sensitive and without further
action, some stuff will likely break.

The draft announcement is here:

---------- Forwarded message ----------
> From: [email-masked]
> Date: Fri, 06 Mar 2015 17:25:10 -0800
> Subject: New Version Notification for draft-appelbaum-dnsop-onion-tld-00.txt
> To: Jacob Appelbaum <[email-masked]>, Alec Muffett <[email-masked]>
>
>
> A new version of I-D, draft-appelbaum-dnsop-onion-tld-00.txt
> has been successfully submitted by Jacob Appelbaum and posted to the
> IETF repository.
>
> Name:		draft-appelbaum-dnsop-onion-tld
> Revision:	00
> Title:		The .onion Special-Use Domain Name
> Document date:	2015-03-05
> Group:		Individual Submission
> Pages:		6
> URL:            http://www.ietf.org/internet-drafts/draft-appelbaum-dnsop-onion-tld-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
> Htmlized:       http://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00
>
>
> Abstract:
>    This document registers the ".onion" Special-Use Domain Name.

All the best,
Jacob

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Mar 2015 21:14:35 -0400 (EDT)

On Mon, 16 Mar 2015, Jacob Appelbaum wrote:

> Subject: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

Is this meant to replace or augment draft-grothoff-iesg-special-use-p2p-names ?

> action, some stuff will likely break.

How does the certificate "dead line" affect (non-)DNS for .onion?

I have reviewed the document and I'm not sure what is intended? I think
it is meant as advise to DNS implementors? I guess it is an attempt to
reduce .onion leaks if those happen to hit the DNS infrastructure? If
so, I would think a much shorter document could be written that only
talks about stub resolvers and caching resolvers, stating they should
never forward any of these queries but return something - and I'm not
sure if NXDOMAIN is the best answer if these resolvers cannot go out to
fetch the real DNSSEC proof needed to authoritatively say so. SERVFAIL
might be better.

Although, if draft-ietf-dnsop-qname-minimisation becomes an RFC, and I'm
pretty sure that it will, then actually processing the query would not
leak that much information anymore, as only the "onion." request will
go out (and get cached) and proper DNSSEC proof will come back denying
its existance, without leaking the fake FQDN onion address.

>> Htmlized:       http://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00

 	The Tor network [Dingledine2004] has the ability to host network
 	services using the ".onion" Top-Level Domain.

Well, it does not because there is no Top-Level Domain of ".onion" and
we have the cryptographic proof of that in the root zone.

 	Applications that do not implement the Tor protocol
 	SHOULD generate an error upon the use of .onion, and SHOULD NOT
 	perform a DNS lookup.

If an application does not implement tor, and is not tor aware, it
_will_ do a DNS lookup. You can't really go ask the world to stop
doing that. You need to deal with that fact.

 	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.

Again, stating what software that is not TOR aware should do is a lost
cause. They will just think it is a real DNS query and process it that
way.

Resolvers that do support Tor and that for some "tor reason" are
returning NXDOMAIN are going to hit DNSSEC validation failures if
the application using that resolver is DNSSEC aware. The NXDOMAIN
has to come with some NSEC/NSEC3 proof. In a way, you are lucky
because there is such a the proof - because it _really_ does not exist.
But it means any resolver can return that proof for "legitimate" tor
domains as well, which I would guess is some kind of a security issue
for tor aware applications using a system or network bassed resolver?

    4.  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: Authoritative servers SHOULD respond
        to queries for .onion with NXDOMAIN.

Well, they already do? Because it does not exist!

    Users must take special precautions to ensure that the .onion name
    they are communicating with is correct, as attackers may be able to
    find keys which produce service names that are visually or apparently
    semantically similar to the desired service.

    Also, users need be aware of the difference between a .onion name
    used and accessed directly via Tor-capable software, versus .onion
    subdomains of other TLDs and providers (e.g., the difference between
    example.onion and example.onion.tld).

I don't think an RFC can tell enduers what to do or expect?

    If client software attempts to resolve a .onion name, it can leak the
    identity of the service that the user is attempting to access to DNS
    resolvers, authoritative DNS servers, and observers on the
    intervening network.  This can be mitigated by following the
    recommendations in Section 2

It could also be mitigated by actually configuring a .onion zone, but
your document states that's really unwanted. Why?

Paul

---

From: hellekin <[email-masked]>
Date: Mon, 16 Mar 2015 22:46:57 -0300

On 03/16/15 22:14, Paul Wouters wrote:
> Is this meant to replace or augment
> draft-grothoff-iesg-special-use-p2p-names ?
>
*** This draft only covers .onion, one of the two pTLDs related to the
Tor Project in the P2PNames draft, so the obvious answer is that it
won't replace it.  Now the P2PNames draft certainly can benefit from
this discussion and will be amended accordingly.

I'd rather amend the P2PNames draft and look forward to the adoption of
the 6 pTLDs at once, instead of having to do all the work again TLD by
TLD: again, the argument for a single draft is that all 6 pTLDs present
a coherent set of similar technical considerations (see introduction of
the latest P2PNames draft).

I understand the scope of this draft is to facilitate the adoption of
.onion in the context of resolving the actual need of proper issuance of
SSL certificates for .onion domains.  Of course I would prefer that this
onion draft serves as a solid foundation to focus the discussion of
adopting new Special-Use TLDs without distraction.  Therefore I propose
we don't mention the P2PNames draft in this thread and keep thinking
about Jake's proposal for just .onion.

==
hk

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Mar 2015 22:20:51 -0400 (EDT)

> this discussion and will be amended accordingly.

It seems odd that two documents would be requesting an IANA action for
".onion" ?

> SSL certificates for .onion domains.

Than perhaps I completely misunderstood things? How does this relate to
DNS or DNSOP if it is about issuing SSL certificates only?

Paul

---

From: hellekin <[email-masked]>
Date: Tue, 17 Mar 2015 02:00:59 -0300

> It seems odd that two documents would be requesting an IANA action for
*** Well yes, it sounds like a mistake to me.  But we can also consider
it a god-given gift for people who argued against multiple TLDs in a
single draft to remained focused on the actual objective(s) pursued by
the draft(s).

> DNS or DNSOP if it is about issuing SSL certificates only?
*** Sorry, but I'm not the author, so I can't answer that part.

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 14:55:40 +0000

Hi!

I’m Alec Muffett, I am the other author of this document.

I am a software engineer working at Facebook, and am the lead on the
Facebook over Tor project - https://facebookcorewwwi.onion/

I’ll do my best to answer as many of the extant questions as possible, so
far:

>draft-grothoff-iesg-special-use-p2p-names ?

My understanding is that this is not meant to replace that document, but
instead that this document is a separate one.

Being as I am one of the authors of this document, I believe that my
opinion carries some weight in this matter.

The reason I am not more emphatic in this matter is that the question
as-phrased is essentially about *that* document, not this one, and I do
not speak for or on behalf of Christian Grothoff, author of that document.

Thus, I shall cc: Christian into this message, in case he wishes to
describe his perspective of that document with respect to this one.

>How does the certificate "dead line" affect (non-)DNS for .onion?

Permit me to quote Brad Hill:

Quote: "The end date for the internal names loophole* is October - all
public certs [which are issued] not for public namespaces MUST be revoked
at that point. CAs can continue to issue up to that time, but they all
must expire or be revoked on Oct 1, and no new ones issued. Those certs
are really extremely dangerous, and [Brad has] been working for NINE YEARS
now to make them go away. Can't happen soon enough.” <endquote/>

The “facebookcorewwwi.onion” certificate (please feel free to examine the
SSL certificate issued by facebook.com for details) is currently issued
under a loophole that permits Subject Alt Names to contain "local” and
domain-names.

CA/B Forum have - as Brad hints above - planned to kill such, for some
time.

In Ballot 144, CA/B Forum approved process for formal issuance of SSL
certificates to ".onion” addresses, providing satisfactory means to
attribute ownership.

Note, though, Brad’s comment, "not for public namespaces”, ie: that
certificates will, after October 1st, only be issued for approved public
namespaces.

Thus: ".onion” needs to become a formally approved public namespace.

Hence this document: The goal is seek formal approval of “.onion” as a
TLD.  

I will defer to Richard Barnes and Mark Nottingham regards the larger
aspects of this process, but in passing note that Hellekin’s observation:

Quote: “we can also consider it a god-given gift for people who argued
against multiple TLDs in a single draft” <endquote/>

…is precisely correct; this is a small, simple proposal for (we hope) a
small, simple change, in (ideally) prompt time.

>reduce .onion leaks if those happen to hit the DNS infrastructure?

The goal is to seek formal approval of “.onion” as a TLD; as such, that
the larger DNS community understands the special nature of the onion
namespace is an important thing.

To paint a naive, thumbnail sketch of how “.onion” addresses work:

1) A user creates a RSA key, distinct from SSL or IPSec or any other form
of crypto
2) The user hashes the public key using a specific hash function.
3) The hash, being unfeasibly large, is truncated a bit and the resulting
bitstring rendered as a (currently) 16-character string
4) The resultant string has the word “.onion” appended to it, and the
whole serves as a layer-3-like endpoint in an encrypted peer-to-peer
mesh-type network “cloud”

All communications are protected by RSA under the key of the server which
someone is connecting to.

As is obvious, in this scheme there is no “root zone” for “.onion” and
there is no “directory” either; instead the “cloud” maintains a dynamic
set of mappings from Onion Address to IP Address, which (by design) change
at regular intervals to defeat various attacks.

People are expected to gather the onion address to which they are
connecting via other means, eg: advertising or social media.

By a process of mining arbitrary keys and experimentation, an onion
address which is semi-human-meaningful can be established in order to make
things easier for people, eg: blockchainbdgpzk.onion or
facebookcorewwwi.onion

However, to reinforce: there is no root zone, no centralised directory.
You can see elements of the underlying entropy of the hash in the “dgpzk”
of “blockchainbdgpzk.onion” - these are actually binary strings with a
hint of human readability, rather than “domain names”, and thus no
centralised repository is required since they can be accessed via
mechanical discovery, quite similar to “192.168.1.1” is accessed via ARP &
Routing.

But, again by analogy to IPv4, you can see the potential risk to
192.168.1.1 if someone were to register a “.1” top level domain, however
silly a concept that might be.

Hence the importance of DNS being (at least) slightly aware of “.onion”.

Plus, as noted elsewhere, information leaks
("whom-is-accessing-which-sites") are often considered risky, by Tor/Onion
users.

[deletia]

>we have the cryptographic proof of that in the root zone.

Which is what the document seeks to address.

>doing that. You need to deal with that fact.

I understand your point, and reality is a good check; by analogy though,
most (?) programmers are aware not to try looking up “192.168.1.1” in a
the “.1” top-level domain, and I hope this “should not” phrasing will
grow, with the establishment of “.onion” as a TLD, to reflect similar sane
practice.

>cause. They will just think it is a real DNS query and process it that

Quite. That is, indeed, how it currently works.

When we launched the Facebook Tor Onion we were concerned that malicious
people would seek to attack users by setting up local DNS resolvers to
point a DNS address of “facebookcorewwwi.onion” to a malicious IP address,
and then persuade users with non-Tor-capable browsers to access it.

This concern was fortunately mitigated by our broad use of SSL; but this
threat model understores the importance of proper SSL certification and
putting “.onion” on a proper footing as a TLD and within DNS.

With the aid of CA/B Forum Ballot 144, the first portion of that risk has
been addressed - it should become astonishingly hard to generate an
acceptable SSL certificate for an "onion address” for use on the IP-based
network space.

[deletia, apologies, I am going to skip some stuff and seek to revisit it
later, due to time constraints.]

>I don't think an RFC can tell enduers what to do or expect?

Actually, I feel that an RFC can tell users what to do and/or expect.

That’s what “documentation” is *meant* to be for. :-)

But, again, I think I take your point.  Do you feel the wording is perhaps
too aggressive?

    - alec

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 17 Mar 2015 16:16:02 +0100

> describe his perspective of that document with respect to this one.
It's pretty simple. The 2nd draft doesn't obsolete or replace the first
one,
it's a Lex Facebook, just like reserving ".local" was a Lex Apple.  I'm not
generally against those at all, but I personally dislike that IETF
passes things
quickly if they are backed by multi-billion dollar companies, while putting
up high hurdles (and delays are obstacles) for proposals that are just
as sound but do not come with such support.  Corporatocracy at its best.

Now, if Alec thinks there is anything in his draft that is not covered in
our original draft, I'm sure we can merge them as there is nothing in
the Lex Facebook on the technical side that we would disagree with.

So one could view this as the political-compromise draft: the
multistakeholder
process is designed to deadlock on almost everything, except for what
the corporations need (as they represent a sufficient number of the
"stakeholders").

Anyway, that's my perspective, Jake is more optimistic ;-).

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 08:58:48 -0700

Hi,

> On Mar 17, 2015, at 8:16 AM, Christian Grothoff <[email-masked]> wrote:
> I'm not generally against those at all, but I personally dislike that IETF
> passes things quickly if they are backed by multi-billion dollar companies, while putting

I doubt arguments of this nature are particular helpful.

My personal observation is that one of the problems with your draft is that due to the unrelated nature of the strings in question, it gives the impression of "buy one, get five for free". This unsurprisingly resulting in arguments about whether some of the proposed strings are or are not appropriate for special names status and loss of focus. More progress might be made if they were split out into independent (where appropriate) proposals. Or it might not.

But of course, conspiracy theories are much more entertaining.

Regards,
-drc

---

From: hellekin <[email-masked]>
Date: Tue, 17 Mar 2015 13:09:08 -0300

> I doubt arguments of this nature are particular helpful.
*** I feel obliged to reflect this to you.

> My personal observation is that one of the problems with your draft
>
*** Maybe you should direct comments on the P2PNames draft to the
P2PNames conversation.  Your comment suggests that the Introduction
section of the draft did not convince you, yet you didn't say anything
about it, which demonstrates the lack of interest in moving it forward.

Now, as I said before, Jake and Alec's draft offers an opportunity to do
actual work on one of the P2PNames pTLDs without the distraction of such
argument you put forward.  Can we please do that?

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 16:20:25 +0000

Before this discussion becomes derailed by discussion of the strategies of
the contents of other proposals, I would like to round this discussion
back to the matter of the draft-appelbaum-dnsop-onion-tld-00.txt document:

Christian’s response clearly distinguishes the separateness of Jake & my
document "draft-appelbaum-dnsop-onion-tld-00.txt” from his
“draft-grothoff-iesg-special-use-p2p-names”.

I believe this clearly answers the question that Paul Wouters raised in
his first response.  The two are separate enterprises.

In my previous e-mail I have outlined the goals of
“draft-appelbaum-dnsop-onion-tld-00.txt” and will happily address any
further questions.

May I please request approval to post to the list in order to respond to
any further questions? I am a newbie to DNSOP and am unsure whether,
having subscribed and responded to one submission confirmation, whether
this means my future posts will be automatically approved.  I guess that
I’m about to find out.

    - alec

--
Alec Muffett
Security Infrastructure
Facebook Engineering
London

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 09:42:42 -0700

Hellekin,

> On Mar 17, 2015, at 9:09 AM, hellekin <[email-masked]> wrote:

Actually, I did comment on draft-grothoff. Several times. In fact, in response to you back in January (http://www.ietf.org/mail-archive/web/dnsop/current/msg13054.html), I said:

"...
Overall:

As with previous versions of this draft, I believe it should be broken up into separate drafts for each of the proposed 6761 special names registry entries.
..."

Regards,
-drc

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Mar 2015 12:59:25 -0400

Not being on DNSOP, I may be missing context here, but this exchange jumped

> >doing that. You need to deal with that fact.

The entire point of the special use domains registry is to tell general
clients how to behave with regard to special-use names.  It exists
precisely to tell the world the DNS names for which they should not do
lookups, because they require different handling.

--Richard

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 17 Mar 2015 17:10:59 +0000

> this means my future posts will be automatically approved.  I guess that
alec

By subscribing to the list, you've got approval to post, as long as you 
follow common sense, which is documented in the "Note Well" documents:

	http://www.ietf.org/list/

This whole discussion is actually useful, and the working group chairs 
(myself and Suzanne) just wrapped up a call with Joel (our amazingly 
wonderful Area Director for those following along at home) and while we 
will discuss these in Dallas, time is tight and we have a direction 
which we will share later today.

tim

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 10:17:47 -0700

Alec,

> “draft-grothoff-iesg-special-use-p2p-names”.

Yes. Hopefully, a revised version of draft-grothoff will be provided at some point, however that's unrelated to your draft.

> “draft-appelbaum-dnsop-onion-tld-00.txt” and will happily address any

Some thoughts on draft-appelbaum:

* In section 2:

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

I might revise the second sentence to say:

"Applications that do not implement the Tor protocol will be unaware of the special treatment of the .onion domain, however in keeping with all names found in the Special Names Registry, such applications SHOULD generate an error upon use of .onion names and MUST NOT perform a DNS lookup."

(this makes the assumption that namespace defined by the Special Names Registry is not the DNS namespace)

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

I'd probably revise this to:

3.  Name Resolution APIs and Libraries: APIs and libraries that implement
    the Tor protocol MUST either respond to requests for .onion names by
    resolving them (see [tor-rendezvous]) or by responding with
    NXDOMAIN.  APIs and libraries that do not implement the Tor protocol
    will be unaware of the special treatment of the .onion domain, however
    in keeping with all names in the Special Names Registry, calls with
    .onion names SHOULD generate an error and MUST NOT perform a DNS
    lookup.

"  4.  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: Authoritative servers SHOULD respond
       to queries for .onion with NXDOMAIN."

In both of these, why not "MUST" instead of "SHOULD"?

In section 4:

" .onion names are often used provide access to end to end encrypted,"

Probably should be "... used to provide ...".  Stylistically, might also say "end-to-end".

Hope this helps.

Regards,
-drc

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 17 Mar 2015 14:30:54 -0300

Considering .onion is a non-resolving TLD, how would a CA issue a certificate for a .onion name that they can't verify whether the requester is the administrator of that service ? DV certificates can use lots of mechanisms to verify that, but is one of them feasible for CAs to use ? 

Rubens

> Em 16/03/2015, à(s) 19:16:000, Jacob Appelbaum <[email-masked]> escreveu:
> 
> Hi,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: David Cake <[email-masked]>
Date: Wed, 18 Mar 2015 01:36:37 +0800

> On 17 Mar 2015, at 10:55 pm, Alec Muffett <[email-masked]> wrote:

	More details on the dangers associated with these certificates in the context of an active gTLD expansion especially in ICANN SSAC document SSAC057
 https://www.icann.org/en/system/files/files/sac-057-en.pdf <https://www.icann.org/en/system/files/files/sac-057-en.pdf>
	As per that document, ICANN security team have been among the groups pressuring to have the local namespaces loophole closed for at least a couple of years now. And the problem has scuttled some gTLD applications that are regarded as too tainted by the issue already (e.g. .corp).

	I agree with Richard Barnes that the special purpose behaviour of .onion always returning an NXDOMAIN where possible to prevent information leakage is enough to justify its inclusion on the Special-Use List. While it will be difficult to update all resolver implementations everywhere it shouldn’t be hard to achieve significant compliance (can’t you implement this requirement with a very small amount of RPZ config?), and thus significant mitigation of the information leakage issue can be achieved.
	I’m generally in favour of this proposal.

	David

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 10:49:13 -0700

Hi,

>  https://www.icann.org/en/system/files/files/sac-057-en.pdf <https://www.icann.org/en/system/files/files/sac-057-en.pdf>
Yes.

> 	As per that document, ICANN security team have been among the groups pressuring to have the local namespaces loophole closed for at least a couple of years now. And the problem has scuttled some g…

To be clear, the CA stuff isn't the sole reason applied for gTLDs like .corp were 'scuttled' -- the large number of queries for .corp and .home (in particular) seen at the root suggested the risk of name collision was too high (see https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/ <https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/>).

> 	I agree with Richard Barnes that the special purpose behaviour of .onion always returning an NXDOMAIN where possible to prevent information leakage is enough to justify its inclusion on the Specia…

The risk of information leakage will remain as long as the query leaves the local machine (making the assumption that the local machine can be trusted).  This risk will remain as long as APIs/libraries do not consult the Special Names Registry and don't forward names in that registry to the DNS for lookup (read: a very long time). Qname Minimization may help in the future (assuming it moves forward), but given the circumstances of folks who rely on .onion, I don't think that can be relied upon.

> 	I’m generally in favour of this proposal.

+1

Regards,
-drc

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 18:02:27 +0000

Rubens, allow me please to direct your attention to:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names
/

Aside: EV certificates are what will be issued for Onion addresses, even
wildcard onion address certificates, for reasons explained on the Ballot.

- alec

On 3/17/15, 5:30 PM, "Rubens Kuhl" <[email-masked]> wrote:

>Considering .onion is a non-resolving TLD, how would a CA issue a
>certificate for a .onion name that they can't verify whether the
>requester is the administrator of that service ? DV certificates can use
>lots of mechanisms to verify that, but is one of them feasible for CAs to
>use ? 
>

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Tue, 17 Mar 2015 18:06:44 +0000

+1
________________________________________
From: DNSOP [[email-masked]] on behalf of Richard Barnes [[email-masked]]
Sent: Tuesday, 17 March 2015 17:59
To: Alec Muffett
Cc: Christian Grothoff; dnsop; Mark Nottingham; Brad Hill; Jacob Appelbaum; Paul Wouters
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[snip].

>doing that. You need to deal with that fact.

The entire point of the special use domains registry is to tell general clients how to behave with regard to special-use names.  It exists precisely to tell the world the DNS names for which they should not do lookups, because they require different handling.

--Richard

[snip].

---

From: David Cake <[email-masked]>
Date: Wed, 18 Mar 2015 02:17:22 +0800

> On 18 Mar 2015, at 1:49 am, David Conrad <[email-masked]> wrote:

	Yes, quite right, there are a lot of issues with name collision in general, and those three in particular leak a lot. Decision not to delegate was wise.

> The risk of information leakage will remain as long as the query leaves the local machine (making the assumption that the local machine can be trusted).  This risk will remain as long as APIs/libra…

	Yes, and in this respect .onion would be no different to other names on the Special Use Names list, so the list can be regarded as mitigating the issue at best.
	It isn’t the worst information leakage issue for most .onion users, and in general those issues, like this one, result from users using services that they intended to only access when tor is running when it is not ( e.g. associating a P2P GUID with non-TORed IP). There is a limited amount that can be done about that. The best communications security is still vulnerable to operational security failure. Which is no reason not to try.

	David

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 17 Mar 2015 15:34:29 -0300

> On Mar 17, 2015, at 3:02 PM, Alec Muffett <[email-masked]> wrote:
> 

And where in this ballot is there a need for explicit reserving of .onion, since CAs already know they shouldn't try using DNS in the process of verifying a .onion certificate ? 

> wildcard onion address certificates, for reasons explained on the Ballot.

I would rather consider them DV due to the nature of the proposed validation, but that's likely off-topic in DNSOP... 

Rubens

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 19:01:26 +0000

Hi Rubens!

On 3/17/15, 6:34 PM, "Rubens Kuhl" <[email-masked]> wrote:

>> 
>And where in this ballot is there a need for explicit reserving of
>.onion, since CAs already know they shouldn't try using DNS in the
>process of verifying a .onion certificate ?

If I correctly understand the direction of your question, that is, in
fact, why this document is here for consideration.

Consideration by DNSOP is relevant to taking forward the matter of putting
“.onion” into the special use domains registry, per the previous e-mail by
Richard Barnes, as viewable at:
http://www.ietf.org/mail-archive/web/dnsop/current/msg13765.html

>I would rather consider them DV due to the nature of the proposed
>validation, but that's likely off-topic in DNSOP...

Indeed, I would agree that it is off topic for DNSOP, and I would also
note that CAB Forum consider the matter decided to their satisfaction, and
that they have voted and agreed the matter.

If review of their deliberations would interest you/others, may I please
direct your attention to the CABForum list and the thread at
https://cabforum.org/pipermail/public/2015-February/004922.html where the
ballot was approved, prior to voting.

    - alec

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 17 Mar 2015 16:15:34 -0300

> On Mar 17, 2015, at 4:01 PM, Alec Muffett <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Rubens!
> 
> On 3/17/15, 6:34 PM, "Rubens Kuhl" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>> 
> http://www.ietf.org/mail-archive/web/dnsop/current/msg13765.html <http://www.ietf.org/mail-archive/web/dnsop/current/msg13765.html>

.onion was already under consideration under other drafts, but now there is a request specifically for .onion alleging time sensitiveness. But on the TLD-level, the only possibility of it becoming a response different from NXDOMAIN is a possible new gTLD round, something that is many years in the future... so the point for a .onion-specific work instead of it becoming part of a larger effort still escapes me. 

Rubens

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 19:36:40 +0000

Hi Ruben,

As I think you’ll see from the document, in our seeking classification of “.onion” in the “special use domains registry” under the terms governing that space, I think it’s fair for me to say that NXDOMAIN is pretty much what we’re shooting for.

There are probably some edge cases to the argument which should be clarified by more experienced DNSOP hands than I - Richard? -  but overall I think we are in agreement regarding that aspect of the outcome.

As for the “alleged” nature of the time-sensitivity, may I please direct your attention to:

…specifically:

“Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name.”

…which I think would best be described as a “concrete” rather than “alleged” time sensitivity.

    - alec

From: Rubens Kuhl <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 17, 2015 at 7:15 PM
To: Alec Muffett <[email-masked]<mailto:[email-masked]>>
Cc: dnsop <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 17 Mar 2015 16:44:35 -0300

> On Mar 17, 2015, at 4:36 PM, Alec Muffett <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Ruben,
> 
> https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ <https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/>
> 
> …specifically:
> 

The ballot explicitly calls .onion an specified non-internal name, so whether the IETF defines that as non-delegatable doesn't really seem to matter to CA/B Forum, does it ? 

Rubens

---

From: Alec Muffett <[email-masked]>
Date: Tue, 17 Mar 2015 19:51:20 +0000

Hi Ruben,

Perhaps you have some greater point in mind regarding this observation, could I ask you please to expand on it, so that I understand better what aspect is interesting you?

    - alec

Date: Tuesday, March 17, 2015 at 7:44 PM

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Mar 2015 16:16:17 -0400

On Mar 17, 2015, at 3:15 PM, Rubens Kuhl <[email-masked]> wrote:
> so the point for a .onion-specific work instead of it becoming part of a larger effort still escapes me. 

It's easier to get consensus on one thing than on many.

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 14:28:30 -0700

+1

What benefit does tying a bunch of unrelated strings together bring in arguing for Special Name status?

Thanks,
-drc

---

From: hellekin <[email-masked]>
Date: Tue, 17 Mar 2015 18:37:23 -0300

> in arguing for Special Name status?
*** I know you already replied that you already commented the P2PNames
draft, but frankly my response should be pasting the whole Introduction
of it here, because you don't seem to have read it at all.  Maybe you
would like to comment on it, instead of saying those strings are unrelated.

==
hk

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Mar 2015 18:10:16 -0400

> would like to comment on it, instead of saying those strings are unrelated.

The problem with draft-grothoff-- is not that the strings it proposes to standardize are unrelated.   Whether they are related or not is immaterial.   The problem is that there is more than one such string, and consensus depends on the least popular string listed.   By separating out .onion, we give ourselves a better chance of actually getting consensus in the short term.

It could be that proponents for some of the other strings in draft-grothoff-- would prefer that onion not be separated out in hopes that this will make it more likely that the other strings mentioned in draft-grothoff-- can ride on the coattails of .onion, which seems like a shoe-in.   However, anyone who thinks this has minimal experience with DNSOP.   Such a belief would be overly optimistic.   In fact, if there is anything that elicits strong objection, it will hold up the whole draft, no matter how much consensus there may be on the more popular names.   This is precisely because we operate on the basis of rough consensus, not on the basis of popularity.   So tacking something less popular onto something popular does not get the less popular thing support: it robs support from the more popular thing.

I think it's actually more likely that we will get consensus on the individual names in draft-grothoff-- if they are broken out into separate drafts and discussed separately, because, again, it's easier to get consensus on one thing than on a bunch of things.   Even though some of the proposals may not attract the same popular sentiment as .onion, having careful, focused discussions on each one is much more likely to bring us to consensus than trying to have a broad discussion encompassing all of them at once.

So please stop arguing that draft-appelbaum-- should be dropped in favor of draft-grothoff--.   This is going to delay .onion, and it is not going to speed up anything else.

---

From: hellekin <[email-masked]>
Date: Tue, 17 Mar 2015 19:29:37 -0300

On 03/17/15 19:10, Ted Lemon wrote:
> 
> The problem is that there is more than one such string, and consensus
depends on
> the least popular string listed.
>
*** RFC 6761 reserves multiple in-addr.arpa. domains, example under
three TLDs, plus .test., .invalid., and .localhost..  I certainly hope
that was because it made technical sense, and not because of their
popularity--you used that word a lot, but its technical meaning still
escapes me.

> 
> So please stop arguing that draft-appelbaum-- should be dropped in favor of
> draft-grothoff--.
>
*** If there is anything in what I wrote that made you think I did so, I
apologize.  I certainly consider having done that draft independently of
ongoing work was a mistake, but I also argued in favor of pursuing a
focused discussion, did I not?

==
hk

---

From: David Conrad <[email-masked]>
Date: Tue, 17 Mar 2015 16:50:36 -0700

Hellekin,

> Maybe you would like to comment on it, instead of saying those strings are unrelated.

I could, but my primary reason for not being particularly interested in your draft is because, as I've said repeatedly, I believe the 6 different strings should be grouped into 4 different drafts, each focused on the logical functional grouping of the protocols (i.e., ONION/EXIT, GNU/ZKEY, I2P, and BIT).  I believe different arguments can be made for whether or not each of those four should be progressed and bunching them together means progress is constrained by the group that has the least support. I personally think ONION/EXIT is a reasonably easy case to make, hence I'm supportive of draft-appelbaum.  Since I don't know that much about the other 3 groupings, I'm not that supportive of the draft as a whole -- this isn't to say I'm against, just that I don't know enough to comment positively. You might also gather from the lack of interest in the rest of the working group that others may be making a similar calculation (or not, I've no idea -- it might also be your style of interaction on the mailing list).

Just my opinion, ignore if you like.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Mar 2015 20:59:20 -0400

(cc:s trimmed)

> as sound but do not come with such support.  Corporatocracy at its best.

I really have to object to this absurd claim.  RFC 6762 came out in
2013.  The -00 of the draft that became 6762 has a date on it of 2001.
It's hard to see 12 years as "quickly".

> our original draft,

That's not the problem with your original draft.  The problem with
your original draft is, as I've pointed out more than once, that it
treats a bunch of rather different cases as though they're the same.
They're different in detail, and therefore they ought to be split up
and processed independently.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Mar 2015 21:11:15 -0400

> lookups, because they require different handling.

Actually, my understanding is that the point of the special use
domains registry is to create a repository for applications so that,
_if_ they are looking at names in domain name slots and trying to do
something sensible, they know where to look to learn about those
sensible things.

There is no way for a document to specify, "Don't look stuff up in the
DNS."  If we had a reliable way to make that rule, AS112 wouldn't have
been necessary.  I think there's nothing wrong with the document
saying that you _shouldn't_ look them up, because they're promised not
to give you a response anyway so it's just pollution traffic.  But do
not delude yourself into thinking that adding stuff to the special
names registry will do anything to prevent leaking.  It will not.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Mar 2015 21:53:26 -0400

> names registry will do anything to prevent leaking.  It will not.

Absolutely.  The only nit I would pick with the above is that it's
perfectly possible to *specify* what should be done, but of course one
should not expect that to instantly change everyone's behavior.

Clearly, publishing this document will not instantly stop leakage.  But
providing good guidance to implementors can help stop it sooner in more
cases -- at the recursive resolver instead of the root; at the stub
resolver if not the recursive resolver; at the client if not the stub
resolver.

Reducing leakage is also not the only benefit of getting this traffic off
the DNS.  It seems like lowering the rate of bogus queries would be an
operational plus.  Stopping the queries sooner also makes software fail
faster and more cleanly.

--Richard

---

From: Tom Ritter <[email-masked]>
Date: Tue, 17 Mar 2015 20:20:37 -0700

On 17 March 2015 at 10:49, David Conrad <[email-masked]> wrote:
>> On 17 March 2015 at 10:36, David Cake <[email-masked]> wrote:
>>
>> I'm generally in favour of this proposal.
>
> +1

I also support this draft.

CA issuance for .onion post-October is dependent on this draft, and
external reliance on an RFC (or lack of RFC) by some date is not
particularly uncommon. It's not a reason to rush a draft through of
course, but it is why we are hoping people can consider the technical
merits of the draft and raise substantive (and editorial) concerns.

To the discussion of aborting lookup, returning NXDOMAIN locally, etc
- everyone understands that this is not guaranteed to occur - but we
can hope it will, and can point people to this document as
encouragement. And even if no software conforms to these guidelines,
having .onion in the special use registry is still appropriate and
useful.

-tom

---

From: Florian Weimer <[email-masked]>
Date: Wed, 18 Mar 2015 11:37:41 +0100

On 03/17/2015 04:16 PM, Christian Grothoff wrote:

> quickly if they are backed by multi-billion dollar companies,

The reservation of “local” took more than a decade if I remember
correctly, and it did not benefit just Apple.

-- 
Florian Weimer / Red Hat Product Security

---

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Mar 2015 19:18:12 +0000

On 3/17/15, 21:53, "Richard Barnes" <[email-masked]> wrote:

>The only nit I would pick with the above is that it's perfectly possible
>to *specify* what should be done, but of course one should not expect
>that to instantly change everyone's behavior.

A preamble - I don't think what is "perfectly possible" matters.  In an
environment that has an unbounded population it's a waste of time to
document a rule saying "this is how you must/should/ought to behave if
only because enforcement (testing) is impractical.  What you can do, in
such an environment, is focus on individual reactions to the stimuli -
like - when you get asked a question, reply like this.

If you are writing to a bounded population of actors, you can spell out
rules that define membership and what it means to be a member.
Nevertheless, you have to account for the unbounded population of
non-members knowingly or unwittingly getting in the way.

Sometimes the underlying concept is perfectly reasonable but the way it is
described has flaws and sometimes the recipe contains poor assumptions.

>From the draft 
(https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-00)

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

I don't know what to make of that.  It's fine, but, to me an onion is
something I buy at the supermarket so if asked about an onion address, I'd
guess a farm.  (Take this lightly, I'm not sure what would be an
appropriate answer - and I couldn't resist.)

   2.  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 <https://tools.ietf.org/html/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.

The first part of the answer is spot-on.  The latter is wrong - for
example, my mail client allowed be to type in .onion and it didn't and
shouldn't complain.  (I turned off spell checking too.)  Trying to specify
what non-Tor-protocol elements will do is kind of useless.

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

This is tricky.  Again, Tor-protocol elements are fair game.  Other
resolvers will fall into two camps, one that would always return NXDOMAIN
so long as .onion is not delegated in the root zone.  It's possible I
stand up a test DNS with .onion, .tomato, .lettuce for testing in my
private lab and that should be okay (until I connect the lab with the
outside world - which I have seen happen).

Same comment as for #3.

Same comment as for #3 and #4.

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

I would drop the latter sentence, the first is a reasonable "suggested
practice" for operators.  I worked at an operator that would let you
configure any domain you wanted, so long as it didn't conflict with others
in its own system.  This had the same pitfalls as certificate authorities
issuing certificates for resources whose responsibility was impossible to
trace, with actually less consequences.  (I'll avoid the temptation to
justify that here.)

   7.  DNS Registries/Registrars: Registrars MUST NOT register .onion
       names; all such requests MUST be denied.

This goes along with my responses to #3, #4, #5 - as far as there never
being a .onion in the root zone.

(Somewhere in this writing, I remind myself that the Special-Use Domain
Name registry is a little bit of an unknown to me, mentioned in another
email earlier today.)

Elsewhere in the draft is this:

"The Tor network is designed to not be subject to any central
   controlling authorities with regards to routing and service
   publication, so .onion names cannot be registered, assigned,
   transferred or revoked.  "Ownership" of a .onion name is derived
   solely from control of a public/private key pair which corresponds to
   the algorithmic derivation of the name.

   Users must take special precautions to ensure that the .onion name
   they are communicating with is correct, as attackers may be able to
   find keys which produce service names that are visually or apparently
   semantically similar to the desired service."

And to me that clearly distinguished these names from the DNS.  "Special
precautions" to me includes the Tor elements protecting themselves from
non-tor-elements either knowingly or unwittingly interfering.  The notion
of a tor name not being subject to an authority hierarchy distinguishes
these identifiers from the DNS model.  It's probably possible to have two
names clash (if I read correctly how the names are derived) which runs up
against the uniqueness principle in DNS, something enforced in IDNA too,
if I believe correctly. I use believe here on purpose because I'm usually
wrong whenever I make any statement about IDNA.

In summary, the draft really ought to address this, and prehaps by
reference - how Tor protocol elements are to behave with the names, what
is requested of external systems to help the Tor protocol, and how the
elements of the protocol protect themselves from non-(compliant-)elements
interfering.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 21 Mar 2015 14:56:51 -0500

> names registry will do anything to prevent leaking.  It will not.

it certainly cannot prevent leakage from resolvers unaware of the new
reservation.

something like  the .alt probably might once iplemented, do so for
future spaces assuming it were used.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 21 Mar 2015 18:12:46 -0500

Dear colleagues,

> > Name:		draft-appelbaum-dnsop-onion-tld

I've read this draft.  I have a few comments.

To begin with, in general I think this document is on the right path
and something very close to it should be published.  It's
narrowly-focussed, I _think_ it meets the template requirements of RFC
6761 (but see a remark below).  It's clearly a technical distinction,
because this approach is a backward-compatible user interface
namespace without any real DNS vestige at all: it's not intended to be
a general-purpose identifier system on the Internet, but rather as I
understand it a cryptographic identifier in the Tor network.

I have a couple nits:

In section 1, it'd probably be useful to pick up the term "domain name
slot" that was introduced by RFC 5890.  This is not an i18n case, of
course, but that's sort of the point: this is an example of something
that more or less fits in places people already use ordinary DNS
domain names, but this name is special and actually not in the DNS as
it shows up in the domain name slot.

In section 4, 3-5, what if a "synthetic" NXDOMAIN gets generated and
cached?  Will that have any effect on .onion resolution?  If this is
explained in detail in some thing I've failed to follow, a simple
reference would be enough.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Mar 2015 11:49:32 -0500

On Sat, Mar 21, 2015 at 6:12 PM, Andrew Sullivan <[email-masked]> wrote:
> and something very close to it should be published.

+1. This is useful.

W

>  It's

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2015 20:40:11 -0000

>narrowly-focussed, 

Agreed.  Let's do these special case TLDLTs (top level domain like
things) one at a time unless there's a group with identical technical
and usage issues.

R's,
John

PS: I wonder how many dusty mail servers still do special case handling
for .UUCP and .BITNET.

---

From: Alec Muffett <[email-masked]>
Date: Mon, 23 Mar 2015 12:57:53 +0000

Hi Andrew,

If I understand your question correctly, you are asking whether in the
instance that a DNS server receives and caches a NXDOMAIN for some/all
.onion, whether that could impact software which uses Tor?

Software which uses Tor does so via a proxy which internally performs the
resolution of the target “.onion” address (or any website, via Tor) into a
TCP-like circuit which connects to the destination server.

Thus the situation should be that either:

a) the software in question is talking to a Tor proxy which acts as a
gateway to the Tor network (and to the rest of the internet-via-Tor) which
resolves ".onion” addresses meaningfully, or else:

b) the software in question is *not* talking to a Tor proxy, and therefore
cannot meaningfully resolve or communicate with onion addresses, nor use
the Tor network.

If the software is somehow both talking and bypassing the proxy, my sense
is that it would be the software's responsibility to deal with the
self-imposed complex situation in a sane manner; an example of this might
be http://en.wikipedia.org/wiki/Tor2web

    -a

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 23 Mar 2015 08:31:08 -0500

First, sorry, I don't know why I wrote "section 4"; this is section 2,
but I think you understood me.

> cannot meaningfully resolve or communicate with onion addresses, nor use

This is what I assumed.  The key point is that it doesn't break
anything that ought to be depending on those onion addresses, so even
if somehow the onion name leaked and ended up in the DNS, it's not a
big deal because it won't negatively affect correctly-implemented
onion-using clients and it won't negatively affect anyone trying to
use onion in the DNS (because there shouldn't be any such person).  

It might be worth adding a sentence or two after the list in section 2
to that effect.  Perhaps, "It is important to note that any
contamination of DNS caches with onion names cannot have a negative
affect on any correctly-operating software.  No application
implementing Tor should be looking these names up in the DNS and no
Tor-unaware application should expect to look up these names successfully."

(I once before had someone claim to me that the latter isn't actually
true, but I think it must be or the description of onion in this draft
is completely wrong.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hugo Connery <[email-masked]>
Date: Mon, 23 Mar 2015 15:08:42 +0100

On 03/23/2015 02:31 PM, Andrew Sullivan wrote:

[snip].

> Tor-unaware application should expect to look up these names

+1.

/Hugo Connery

---

From: hellekin <[email-masked]>
Date: Tue, 24 Mar 2015 19:45:18 -0300

On 03/23/15 10:31, Andrew Sullivan wrote:
> big deal
*** Well, although you're right as far as *applications* are concerned,
this is still a big deal because humans are using these appplications,
and that's the prime interest of having such a TLD reserved in the first
place, that the DNS does not propagate any leak.  So I agree with your
amendment, but not with the "not a big deal" statement, which completely
ignores the fundamental privacy implications of such leaks to the DNS.

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Tue, 24 Mar 2015 23:03:22 +0000

Hi Hellekin!

I would agree that leak avoidance is “a major” rather than “the prime”
point of having .onion reserved as a TLD.

There are many good reasons for reserving “.onion” as a TLD, including but
not limited to:

- avoiding leaks (above)

- not wasting resource on trying to resolve the “.onion” special use
domain name (flipside of above)

- SSL/TLS EV certificate issuance per CA/B Forum Ballot 144

- ...meaning that sites can adopt a “.onion” address without reworking
their HTTPS code

- ...and also that EV site attestation works, to the extent that that may
be valuable (eg: SecureDrop site for <NEWSPAPER>)

- generally putting “.onion” on an official footing / erasing doubt

Folk more creative than I can certainly add to this list, though as you
say privacy (esp: organisations watching for people doing errant onion
lookups) are a risk to the privacy of individual users!

    - alec

---

From: hellekin <[email-masked]>
Date: Tue, 24 Mar 2015 20:13:53 -0300

> point of having .onion reserved as a TLD.
*** Agreed.  I came from the privacy side of the arguments, which tends
to consider human life as more valuable to data retention.

Alec, would you care to explain the differences on the IANA
considerations between this draft and the P2PNames draft for the same
section?  I found more than I can process now, but I guess you already
know about them, and I'd like to hear your reasons.

==
hk

---

From: Alec Muffett <[email-masked]>
Date: Tue, 24 Mar 2015 23:35:13 +0000

>considerations between this 
>draft and the P2PNames draft

Woo! I'm honoured, but I am a considerably less IANA-informed schmuck than you take me for. :-)

I've been heads-down in Tor and the wider Tor community for some time now, and I see the ".onion" TLD as something small and focused which is sensible and doable, and my grasp of the ramifications is that adoption of ".onion" as a special use domain name presents no obvious harm, quite a lot of good (and opportunity) plus might help shape a wider consideration. 

What happens/ed in consideration in other committees, I am not fit to speculate.

-a