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.
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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
