On Mon, May 11, 2015 at 7:21 PM, Alec Muffett <al...@fb.com> wrote:
> Hi Hellekin!
>
> >Since Alec Muffett seems to have better things to do
>
> I'm sorry if you've been waiting for my input - I am not the primary
> author of the document; Jacob Appelbaum's name is in the document's
> title for a good reason, and my involvement has been one of tuning a
> few paragraphs, providing some wordsmithing, and cheerleading loudly.
>
> Jake is - as I am sure you are aware - working for Tor, and is a busy
> guy (last I heard was off in China doing something amazing) hence I
> mailed out the latest draft when there was in extended (and ongoing)
> lull in the desire for anyone on our editorial maillist to tweak it.
>
> I'll do my best to respond to your points, albeit Jake and other
> (wiser?) heads may have additional insights that I may miss by dint of
> this being dropped on me at 10pm the night before the big phone call
> to discuss such matters.
>
> On that basis, you'll also please forgive me excising brevity.
>
>
> > 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.
>
>
> If you are consciously running TAILS, I suppose so [ED: TAILS is a
> Linux distribution which funnels almost all communication through Tor]
> albeit that Tor would likely recommend against using a vanilla browser
> in default configuration to access any part of Tor, let alone ".onion"
> addresses, because risk of deanonymisation is too high with normal
> browsers. Hence the imprecations in favour of informed users,
> reflecting Tor user-policy.
>
> If you are not talking about running TAILS (or similar) then I must be
> misapprehending what you mean by "can use an ordinary Web browser,
> type in a .onion address, and access the requested service" because
> your average browser - say Chrome - cannot access ".onion" without Tor
> software help and some fiddly configuration.
>
>
> > 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.
>
>
> Yeah, we tossed that one back and forth a bit, and eventually if
> slightly grudgingly went with the "SHOULD" on the basis that we wanted
> the draft to be adopted more than we wanted to be thinking wishfully.
>
>
> > 3. this error is confirmed for DNS server operators, where OnionTLD
> >makes it a soft requirement not to override responses.
>
>
> This might be an issue so long as your threat model includes blindly
> unaware users who are typing ".onion" addresses into non-Tor-capable
> browsers in the (presumably first-time) expectation that it will work,
> and using resolver libraries which don't honour the imprecation that:
>
> [draft-appelbaum-dnsop-onion-tld-01]
> Resolvers that implement theTor protocol MUST either respond to
> requests for .onion names by resolving them (see [tor-rendezvous]
> [ED: A TOR-INTERNAL THING]) or by responding with NXDOMAIN.
>
> ...on a network infrastructure which is thoroughly pwned by a capable
> bad actor. Not totally impossible, I'll grant you, but threat models
> which start from the assumption of a wholly ignorant userbase are
> (joking aside) pretty flawed.
>
> Continuing...
>
> [DELETIA]
>
>
> >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."
>
> Please explain the contradiction, I fail to see it?
>
> [DELETIA]
>
>
> >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 ! *
>
> There are entire papers about that. Thank you for raising that point,
> I wanted an excuse to post this URL to the DNSOP list:
>
> https://petsymposium.org/2014/papers/Thomas.pdf
>
> Measuring the Leakage of Onion at the Root - A measurement of
> Tor’s .onion pseudo-top-level domain in the global domain name
> system
>
> ...to help drive home the need for making ".onion" special.
>
To save some time, the headline number is: The rate of .onion requests
hitting the A and J roots is ~200k requests per day and growing.
--Richard
>
>
> As before, ignoring the potential for privacy-leakage of which site
> you are seeking to connect to, this notion of "ZOMG THEY COULD HIJACK
> THE SITE!!!!" is not a problem if you're using Tor-enabled software
> and have awareness of the issue, per the draft security
> considerations.
>
>
> [DELETIA - I WANT TO GO TO BED I HAVE A VERY LONG DAY TOMORROW]
>
>
> Your conclusions mostly seem to be a matter of what you want the RFC
> to look like; that's a matter upon which I shall punt.
>
> You also use the word "competitive" which (at the risk of overcooking
> my interpretation) is a feeling that I have not felt during the
> development of this draft.
>
> I do want to address that, though.
>
> There is no politics being played here. This is not a race between
> RFC drafts, this is a matter of considering a small, neat document
> that delineates how to address one small, and fairly clear, "Special
> Name" problem, seeking to address it properly in the time allotted
> before November 1st swings by and Ballot-144 kills ".onion", possibly
> forever.
>
> I was brought in to help with a largely pre-written draft which -
> as-above - I've merely helped edit a bit. Come to that, Mark
> Nottingham has played possibly an equal role in keeping us on the path
> and helping wordsmith things up to IETF standards, though he seems to
> not want direct credit.
>
> I can't address your larger feelings about the two drafts and the time
> that you committed to one of them, but having been invited to become
> involved with _this_ one, and having edited it a little bit, and
> having pushed it into the queue, I am proud to say that I have been
> involved.
>
> And - speaking as the engineering lead for one of the newest and
> arguably most notorious ".onion" addresses - I feel that it's a pretty
> good document, and one that is fit for purpose.
>
> - alec
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
