[tor-dev] Namecoin .onion to .bit linking

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Tor-Dev,

One of the criticisms of Namecoin which seems to be raised sometimes
is that the current domain namespace spec doesn't have a method for a
.bit domain owner to prove that they are in control of a .onion.
(This is also an issue for .bit domains that point to .i2p.)  I'm
interested in improving this situation, and am looking for feedback.

First off, I'm curious what the various use cases are for this.  The
main use case I'm aware of is if a user is aware of a .onion domain
already, and is trying to find a human-memorable way to access it.
(As far as I can tell, the reverse is not a use case, because if you
already trust the .bit domain by name but don't know what .onion
you're looking for, presumably Namecoin already does what you want.)
Is this correct?  Am I missing any other significant use cases?

Second, I'm looking for feedback on my rough approach.  The approach
I'm looking at right now is to have a Namecoin namespace for .onion
backlinks to .bit domains, which is separate from the Namecoin
namespace for .bit domains.  The backlink namespace would have a name
field whose prefix is the .onion domain.  We can't prevent a squatter
from registering an exact match of the .onion in Namecoin, but by
using a prefix and checking the signature on all matches, we can avoid
the impact of squatters.  (The cost of obtaining new names would be a
deterrent for someone trying to flood a .onion prefix with invalid
backlinks as a DoS.)  The value field would contain a signature of the
domain name being pointed to, signed by the .onion key.  The .onion
key could also sign revocations of an endorsement of a .bit domain;
these would also be in that namespace.  Is this generally a good
approach?  I'm aware that cross-protocol attacks need to be carefully
considered when signing things with a .onion key -- do you have
suggestions on how I can sign a short JSON string of the rough form
{"name": "d/domain", "rev": 0} (which corresponds to endorsing
domain.bit, and not being a revocation of that .bit domain) in a way
that won't open up attacks on the .onion key's normal protocol usage?

I'll write up a more formal spec after feedback is received, just to
make sure I'm not missing some important details.

Cheers,
- -Jeremy Rand
https://namecoin.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVW0v7AAoJEAHN/EbZ1y06C+AP/3RxO99cPoBQ6eRcY9cefqlC
HGnfUtxfAa7Ao2Ea2ZatHjA36ordtz6vo9UpJKDXXLPuQFMnsW/Xf6m2ePCKPssG
uivWnAqoZ/zFaJFXf6RqgADrbUei7jW75DFmJfwhPka3kh76mF/B3mMIRx9bCOIq
r8XcKRlmbFv55j0srg2Z6SBpq8aMumxGjStjyzsW8L6bVtBvz4DwN5rAZG958Hm3
ji7b6r+v05s4dIbJ6ZAqerOVmy6PA+sAZ0cqwzCBBttdIoVzGiuc9S6aAn8+XjWa
ycx7wUi3YM27Kyor8N2+pYDgECmMYEC9QBKN6XwtsW6Lwz9UCNaZ4BQR5JWIxwLg
FTZ1uV/E7o3cKdiPzlCkzoQetifom8la6ezPOpr4XhVuzLWqHJBm4eA+qEwEPSFC
DA4k/HEgJKNUZGFWuXpIyEAl3Nvyy3cxTYyrzzMmbvBJnzMGM18Sa+D9N78ih3Sw
GgXIET336wnvd+HqcVT85io7Ee3Wj+05IOyH4mhV06AXJuP1RvFAKJk6d1i5lOKC
Sr2GrJNnP8zP1uq57XQxpKg7fkVqBMzjFY9JJ6HIkffLsGzLpZ8CUSU2+8tPGeDt
T3MAT3GKqXCIjIiQy39Ban27ixeJyxzq8dN3T2HvnUNna0M9v3VhxQjeauNzjHTk
9ekMPDGGT7X9TmLOvSXq
=WbCd
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Namecoin .onion to .bit linking

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/19/2015 10:02 AM, Daniel Martí wrote:
> I'm not familiar with Namecoin, but I thought I'd just point out
> that someone will be working on OnioNS, the onion name system, as
> part of the SoP in Tor. The person who will be working on it just
> sent an e-mail to this very list yesterday.
> 
> You two seem to be after the same "human-readable way to access
> .onion domain names" target as you yourself described, so there
> might be room for collaboration.

I'm aware of OnioNS, but haven't yet had time to thoroughly read the
proposal.  It's certainly on my to-do list, if nothing else for
cross-pollination of ideas.

- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVW1WyAAoJEAHN/EbZ1y06VmgQANTvkb4YiQ513LKSERk77wFD
hNIhyFhcawSGXW1/GcJ8JJSxH1Z/MZrqVKaxYvly+qjdKKGwifX4VfAbWBhorolb
1RGIeqaI2ew++c0Ofj0wvDmpiEkYiXeA+7hJyVFhQV2RN9lSwOCzuWp6Ipoh7OZc
FZdwq+RHHjoyq4jGehA8BM9lgGnSASryVOndRs7CSvz1dNBuHDaKL5M5vXaF0Sio
d/+GjsIgUbAIC7qxWYawWkIbaayL2pw5kKE5Mgvb94b9S4yPp4LUWOVMcF6bHN9n
nu8mMbMbShLVchShXlWVhits2eRmD65Y4rFkf8m0wwyNA4G/HvoEInDcq+kF6jiX
HjApkn1lQVZlvM/+8ijt98JzAK+nb8RgUvxoenlYo89eJUee5H7gE0i1nL8zatOG
hJKvbp1zObqCDkw0LC03NKUiLcoKKniXPgHcYAzLPjB7H4ke+8luV8PVcF80TJN+
DirVSxcXvbOs9OB9ooXb2peZeH73JmBz54BdTcHNr7UELCyF6Kft9pmr4idEIorJ
f/qP48F36QuFFdbqKs1A/wwsQFrWskirtHWDX6CiFFoTRlcbhC2G0aWWkZXqK0q4
fSwlmTFDdNkIYPb5DBVhArLlcoi77jPtm8CMYH1VLvOCvA8KS1hZYzZwD6iOr/0E
j/hbIs/FfMLLMHULxgnf
=d+xp
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Namecoin .onion to .bit linking

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/19/2015 03:31 PM, OnioNS Dev wrote:
> 
> 
>> On 05/19/2015 10:02 AM, Daniel Martí wrote:
>>> I'm not familiar with Namecoin, but I thought I'd just point
>>> out that someone will be working on OnioNS, the onion name
>>> system, as part of the SoP in Tor. The person who will be
>>> working on it just sent an e-mail to this very list yesterday.
>>> 
>>> You two seem to be after the same "human-readable way to
>>> access .onion domain names" target as you yourself described,
>>> so there might be room for collaboration.
>> I'm aware of OnioNS, but haven't yet had time to thoroughly read
>> the proposal.  It's certainly on my to-do list, if nothing else
>> for cross-pollination of ideas.
> 
>> - -Jeremy
> Yes, I'm here. Last year I explored Namecoin as a possible 
> alternative DNS for Tor hidden services.

Indeed, we conversed a few times last year about that topic.  I'm
quite looking forward to catching up on what you've come up with since
those early conversations -- more ideas are always a good thing.

> I spent some time over it, but I also ran into the same problems 
> previously mentioned above: how to link HS RSA keys to Namecoin
> ECDSA keys. I came up with two solutions: sign the Namecoin key
> with the HS key and embed that signature in the blockchain, or
> introduce a new blockchain that relied on the same cryptography as
> hidden services (RSA, Ed25519, ECDSA, etc, as long as they
> matched).

I hadn't actually thought of the idea of using a parallel blockchain
with different signature opcodes as a solution for this particular
problem.  I'm not sure if you're aware, but some people have proposed
creating altcoins that use quantum-resistant signatures such as
Lamport signatures just in case such quantum resistance turns out to
be useful, so that actually isn't as crazy an idea as some might assume.

Generally for this purpose, I think signing a Namecoin name with a HS
key makes more sense than a parallel blockchain.  Signing a Namecoin
*address* (what I assume you mean by key) would be harder, because
Bitcoin-based currencies like Namecoin intentionally don't reuse
addresses, so a name will get transferred to a new address every time
it is altered or renewed.  Of course, then you need to deal with the
ability for the .onion key to revoke a Namecoin name's authority.

> As I mentioned in the ACM paper, it's non-trivial to build this 
> correlation and I came to the conclusion that solutions would look 
> more like a hack than an elegant solution.

Certainly not trivial, but it doesn't seem like an overly complex
issue to attempt, to me.  But that's why I'm asking for feedback --
I'd prefer that any solutions have holes poked in them before
implementation effort is expended on them, and certainly you've
expended a lot more thought on this particular topic over the past
year than I have.  The biggest issue I'm aware of is cross-protocol
attacks... are there other pitfalls you've encountered that I should
be aware of?

> Moreover, even if the correlation could be built, it's impractical
> to require clients to download the whole blockchain before use, so
> you still have to address the issue of preventing name servers
> from lying.

SPV-based systems appear well-suited to solve that problem for most
cases.  HashEngineering created a Namecoin port of the BitcoinJ SPV
library (it only took him a few days, I think), and used it to create
an Android Namecoin client.  He didn't implement parsing of the name
script opcodes, but that's not a super-complicated thing to do.
Almost all of the code in Namecoin is the same as Bitcoin; the
differences are pretty minimal, so Bitcoin's lightweight client modes
such as SPV work pretty much verbatim when applied to Namecoin.
Actually getting a working product that handles the name opcodes is
mainly a matter of implementation rather than any novel engineering.

SPV by itself does allow a peer to falsely claim that a name hasn't
been updated after the block that the SPV proof is for.  Daniel Kraft
(Namecoin's chief scientist) is experimenting with a fix for that, by
having miners place a merkle trie commitment of the unspent name set
in each block's coinbase transaction, whose accuracy would be enforced
by blockchain validation.  This mode (abbreviated SPV+UNO-CBC) would
ensure that name values returned over SPV are current (up to a
sufficient block depth to avoid a lucky miner being able to mine a few
invalid blocks with bad commitments; 12 blocks seems to be reasonable
there).

> I hope you can see that it's a difficult problem. I think Namecoin
>  could use a solution if you come up with one, and I would be 
> interested in hearing about it. I came to the conclusion that 
> Namecoin would not work and wrote something different. Namecoin
> does many things well and I took those good design ideas, but I
> also changed the setup to solve many of its weaknesses. Namecoin,
> GNS, and OnioNS are good alternative DNSs, 

Re: [tor-dev] Namecoin .onion to .bit linking

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/20/2015 04:36 AM, Fabio Pietrosanti (naif) - lists wrote:
> 
> 
> On 5/19/15 4:43 PM, Jeremy Rand wrote:
>> Hello Tor-Dev,
>> 
>> One of the criticisms of Namecoin which seems to be raised 
>> sometimes is that the current domain namespace spec doesn't have
>> a method for a .bit domain owner to prove that they are in
>> control of a .onion. (This is also an issue for .bit domains that
>> point to .i2p.)  I'm interested in improving this situation, and
>> am looking for feedback.
> 
> At Tor2web we've been considering using Namecoin for those
> features:
> 
> https://github.com/globaleaks/Tor2web/issues/30 
> https://github.com/globaleaks/Tor2web/issues/66
> 
> If someone want to hack on those feature, we'd love to support! :)

Ah cool, thanks for the heads up; I wasn't aware that Tor2web was
looking at that use case.  Good to see that there's interest there.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVXahkAAoJEAHN/EbZ1y06IDkP/10y0K27UZgFfUiKdxuCz0Lo
jCYo5HwjD3usluF1nIpMnN29za1HtiqbRPkHmYnXVAx4L9hESB9oyw+2lS0XxDBu
ZmncPhSJR/KTo8HJ3T7DbQsWqXzqUaaxuNCSYJKVRdZLejV6GDVJ57Fy2XlJTQ7p
lQitFASjoH+2uhRa6a6DtHHXCph9LxCo6zvjA0CowEjDWaQYWuYyeL+uDz2bEr4X
Q12t0PYoYFamz2i/3yzg39pyWJN16k7Qmi13DPkQiM2bB4/jNWej471DtZ0dE+KN
dd9bM2srxfQVV/bd4LAB2OFo/zy3PPuAe/VenuZ4gSaW0QZfGEn4Vc09KvxnVFtD
19joxzOsAfvJ+Lk0ma+X7hy/m5G62RLLrcu7m2+4B27GXIVH8mTTx9ooyUDvYeBM
sh0K8XtnTRivXmalg0BvPcVJnOIXD+p22N8mF5CXbBgjfKbKMFZYa6Cb+DNZmwPd
eh/Llb/a4ktS4oo4hy8xZpE0cBGsuTWoomrZK3mFYBmPDggLvzUevUj3TAfIuyWZ
exnVw9ELruIX85K9h/vXF2LxYAyTWyfd5x9mXVeB71KZnUi74NmKL38FcLtZNMTT
OYztzK4FLl2FGcvYKGgdCBmwWB/yPFJBjzHk0HX9cI624IFD4Oh/Ok50oU18Szgg
xG4BEtWm9OwtpEnzY3Nm
=Ed/X
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Dumb or-ctl-filter tricks (Was: [tor-talk] SOCKS proxy to sit between user and Tor?)

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/03/2015 04:07 PM, Yawning Angel wrote:
> Hello,
> 
> I just pushed a fairly large update to or-ctl-filter, that lets you
> do lots of interesting things, most of them probably unsafe.  In 
> particular or-ctl-filter now ships with a SOCKS5 client/server 
> implementation and a stub control port implementation.
> 
> A picture is worth a thousand words: 
> https://raw.github.com/Yawning/or-ctl-filter/screenshots/or-ctl-filter
- -tor-i2p.png
>
>  [snip]

Thanks Yawning, this looks very useful indeed.

- -Jeremy

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVb9z2AAoJEAHN/EbZ1y06U+kP/i2PRpJqRYqGksASUkYCZDcg
q7Z1OLldOlT9EC2xjh8k/dEJi2or6in+hUSZPp6VNi9W3/drKX0t0VAY2zRmQzdr
yfwm4e+FgFkenKUgGB9XOIus589Rclieri3nWhYwBqbOJIWLy9D4Ujassoj7PKpZ
HNQXeg2cS3p2wGnku7NR6K13c2P7ajWV4aykTUJQDYUC2IqFw8LLK9zhxLOC98Lh
WQ2HAtT1GsphC8jAygdk7XTmhOYL7i7n4jFgIhUB9dcI9YnbqxZsE4QrlkDAoiQg
tzIIaJDAbensTFwiuR31cO7jA6yDEZ7Ikm6FhO1W3qW/YtjOs0mWr+zcp6cwOrKZ
0eKwHMRzAKJSNJLe0TIlr3gXbF/c/b8ACBcb6Si/QfeoGLy7nvDKDoi8URvhrmYG
i77Faall1+ycFCWQgwik5JRo2XWWK3tXmMITqEMM3h2G1LOao4rH44QCYvA8xYtA
CbwvVu0+od9eJyIQYk7gfYmP89ZTno/a+XiIgRdWEdLzTiUZb09WgtXM/E/qenG/
p80fNiphH6BhvkUsIWOKooJAs/vgeixM9QCGaTl+Nojvt/nru6PcRJ9hL9ulS8TO
9NxQ5hVu2A2jbGracHcZw9+5u7HqzxfOM9B6mSyYeWJ/T54PFgxT4PCJ3/D1idpk
8EBVAVWJETXTZHHEvHLF
=QjQQ
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/08/2015 11:39 PM, Jeff Burdges wrote:
> On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote:
>> One is to produce human meaningful names in association with 
>> onion addresses. Coincidentally Jesse has just announce to this 
>> same list a beta-test version of OnionNS that he has been
>> working on for the Tor Summer of Privacy. See his message or
>> 
>> https://github.com/Jesse-V/OnioNS-literature
> 
> OnioNS has a relatively weak adversary model, like Namecoin, right?
> It's certainly plausible that's good enough for most users, 
> including all financial users, but maybe not everyone.
> 
> There are several approaches to improving upon that adversary
> model :
> 
> - Pinning in the Name System - If a name X ever points to a hidden
>  service key, then X cannot be registered to point to a different 
> hidden service key for 5 years.  Alternatively, if our name system 
> involves another private key, then X cannot be registered under 
> another private key for 5 years.
> 
> - Pinning/TOFU in the browser - If my browser ever visits X then it
> locks either the .onion key and/or the TLS key permanently. 
> Alternatively pin both but one at a time to change.  Sounds bad for
> Tails, etc. though.
> 
> - Awareness - Just yell and scream about how OnioNS, Namecoin,
> etc. are nowhere near as secure as a .onion address.  And
> especially tell anyone doing journalism, activist, etc. to use full
> .onion addresses.

I'm not 100% sure what you mean by saying that OnioNS's and Namecoin's
adversary models are comparable.  To my knowledge, they're quite
different in the respect that OnioNS relies on a quorum of directory
authorities, while Namecoin relies on a quorum of mining hashpower.
Which is "better" probably depends on your threat model.  I did a
rough calculation about a year ago of how much it would cost to buy
ASIC miners that could 51%-attack Namecoin, and it came out to just
under a billion USD.  Of course, a real-world attacker would (in my
estimate) probably be more likely to try to compromise existing miners
(via either technical attacks, extortion/blackmail/bribery, or legal
pressure).  Note that right now -- though hopefully not in the future
- -- this kind of attack is easier than it should be because a majority
of Bitcoin hashpower (and with it Namecoin) is located in China.  I'm
not sure about OnioNS's design, but in Namecoin's design, a 51% attack
is easily detectable (you'll see blocks getting orphaned in a way that
makes a targeted name not get renewed even though the renewal
transaction is clearly visible and being relayed).  It's also easily
detectable specifically which names were targeted by the attack.

Regarding pinning, there are also some half-formed proposals related
to that for Namecoin, which would make a 51% attack ineffective at
stealing a name (it would instead simply be a DoS attack on that name,
which would cost continued hashpower to sustain).  Personally I'd love
to see these proposals implemented, although getting the appropriate
level of review to make sure everything works as we intend takes some
time.  (This would be a hardfork to the consensus rules, so it takes a
lot of carefulness.)

In any event, security only matters if the end users can effectively
use it.  An end user will be much more likely to notice when a
Namecoin or OnioNS name changes, compared to when a .onion name
changes.  So this isn't really a clear win for .onion -- it's a
tradeoff, and which is more "secure" depends on which end users we're
talking about, and what threat model we're dealing with.  There are
probably a significant number of cases where Namecoin (or OnioNS, or
something similar to either) would defend against attacks that .onion
wouldn't.  (The inverse is, of course, also probably the case.)

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVxtuSAAoJEAHN/EbZ1y06SVoQAMaa03n2/onHeqtwMzfSRwEO
IzrsyrxLCxJhPCAGH4gvuGkU/rqNJRT4BhwwTCvtgoEnYNWe0dxoc29bNM76KR0f
Ksq5//kgm73sDyyeRw4jxP3SpMzucc1BoyTBEeJdYuL8hdBwBwkOrd32C+ee/7vu
/OUzisy68apzQFHZDlXY5HS6rp+vdOj1uKUglhDM9nSx73kSdOnpvuxZm9PfYdaR
OXBmZ9Lhk8hAYKhoxdTI+I5I8KNiCZV/uWkDSfDs+RUuL2dAvdEcP3uq5lQoIGyO
tOgBqBSpBAk39ihA7YplmhL3YSJcQ4yfo4rY68PDby+sGI/quZ5YGJjOEyKW0TF2
uObuDQz+1ajD/WPiaQ9I6xo2jJE2vQkMrqfCe83YsR8oOmpN3f+YWm/fgs/EoDul
tG50rwr76egQL+EphJFYvH35YKAwoXNowDlTpGMMCanRC0pOoQAdpmyPvJv38E56
mZSC42oeFgV/vjnSEtKBtnthfg6GHap87XHp+nX//Ry5v+fxo9t94QyGUrAxQtLQ
0MJ4athw3QTi8QJYa6y1DktbIze5dStqteBKK+W7EvrXxNS0eJYL9vJvKPEyu75x
dqhzFZTsFjinv9Dgn/YG665WlvVpDkc36wn/Cj6yXP1kT2Prpo+ekmdLFxJUiQ9l
zYtb7Vw4vTw0KOzsrH8E
=UgpZ
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Future Onion Addresses and Human Factors

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/09/2015 06:54 AM, Jeff Burdges wrote:
> 
>> I did a rough calculation about a year ago of how much it would
>> cost to buy ASIC miners that could 51%-attack Namecoin, and it
>> came out to just under a billion USD.
> 
> Isn't the 51% attack down to a 20ish% attack now?

The estimate I did was based on Namecoin hashrate, not Bitcoin
hashrate.  I assume that's the distinction you're referring to, though
you're not really making it clear.

>> Of course, a real-world attacker would (in my estimate) probably
>> be more likely to try to compromise existing miners (via either
>> technical attacks, extortion/blackmail/bribery, or legal 
>> pressure).
> 
> Isn't 50ish% controlled by one organization already  Is it not a 
> particularly tight not organization or something?

Of Bitcoin or Namecoin?  Definitely not in the case of Bitcoin (though
50% of Bitcoin hashpower was controlled by one pool, GHash.IO, a year
or two ago).  Pools and miners are not equivalent, because if a pool
does something shady, it's easily detectable and the miners who use
that pool (of which there are many) are free to switch to a different
pool.  F2Pool does have a majority of Namecoin hashpower at the
moment, because several other Bitcoin pools aren't mining Namecoin.
This is, to my knowledge, because those pools are unaware of the newer
Namecoin software (Namecoin Core) and had some problems with the old
Namecoin 0.3.80 code (which was deprecated many months ago in favor of
Namecoin Core).  We're looking at reaching out to pools that aren't
mining Namecoin right now, and I certainly agree that it is not great
that F2Pool has a majority.  If 1 or 2 other Bitcoin pools started
mining Namecoin, that would not be the case anymore.  FWIW, I've seen
no evidence that F2Pool is shady in any way; they've been quite
responsive and supportive.

> Isn't the real world attack that you simply isolate a namecoin user
> from the wider namecoin network?  That's cheap for state level
> attackers.
> 
> I'd imagine OnioNS should have a massive advantage here because Tor
> has pinned directory authorities, who presumably help OnioNS
> accurately identify honest quorum servers.

It's doable to construct a Bitcoin or Namecoin client that
authenticates certain semi-trusted peers to retrieve blocks from, and
panics if it can't securely contact them.  Electrum is an example of
this kind of protocol (though it does SPV verification rather than
full verification of the data it receives).  This is a client
implementation issue (and one that I agree is important), not an issue
with Bitcoin or Namecoin as a whole.

>> An end user will be much more likely to notice when a Namecoin or
>> OnioNS name changes, compared to when a .onion name changes.  So
>> this isn't really a clear win for .onion -- it's a tradeoff, and
>> which is more "secure" depends on which end users we're talking
>> about, and what threat model we're dealing with.
> 
> This is false.  Users must enter the .onion address from somewhere.
> 
> 
> If they go through a search engine, then yes the .onion address
> itself is hard to remember, especially if they visit many sites.
> Key poems address this.
> 
> If however they employ bookmarks, copy from a file, etc., and
> roughly proposal 244 gets adopted, then an attacker must hack the
> user's machine, hack the server, or break a curve25519 public key.
> 
> Yes, a search engine covers .onion addresses should ask users to 
> bookmark desirable results, as opposed to revisiting the search
> engine, mostly for the protection of the search engine.

I think you will find that a number of users are unlikely to
exclusively use bookmarks and not use web links.  Hyperlinks are an
incredibly useful feature which many users are not going to throw out.
 From what I can tell, your argument makes certain assumptions.
Making other assumptions changes the result.  Hence, as I said, "it's
a tradeoff, and which is more 'secure' depends on which end users
we're talking about, and what threat model we're dealing with."

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVxwC/AAoJEAHN/EbZ1y06y74P/2CckbR7wvbJhpnkAugtnRpN
P5lxDFEEfHF/JD5Sq83rKzB0HJXq/3DiQsta/0bZpWaJP3Oaa9rSQpmVRG7UqA0D
RcNHuGnlVG1saAHNgHPk52d6++3j/fE0qcxLkhM6JkeCvMtkXGq/vkzMIVio2/mW
yu4b94hDHKtx9QKNTEME68Zq20OaO7zlb8Fa8ymhM6C3C746pskeILp/AwOLxs3s
WOrhuLPAKbijovFfV4L48fKallywL/PNS1QreF+QHMfaA8OYmbrefRhJraBCmcED
Sc92dh4eLhn8YMU2SuDtoSm6C6N974UF5md4eM9TF64T+vgS8ez0wG/WOtsC72Gy
aJ2kDr+5ZgoUx6VrirKCuWIIUyKlGBViIKkoS2vrrcsBIHtq9IlRFZGjUGo0eI9t
OrVY9A56lgIl7n4lc1lVYquz8lP75QwmkTh7/12jfF3d6uSE6IoQvUXIm41OWIF1
it7vkWuyCEmfTL5k

[tor-dev] Reproducibility of Pluggable Transports python.msi

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I was looking at the Gitian descriptor for the pluggable transports at
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitia
n/descriptors/windows/gitian-pluggable-transports.yml
, and I noticed that it has an input file called "python.msi".
Furthermore, I noticed the following line in
https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitia
n/versions
:

PYTHON_MSI_URL=https://www.python.org/ftp/python/${PYTHON_VER}/${PYTHON_
MSI_PACKAGE}

- From this, I conclude that Python is not being built in Gitian, and
the download from www.python.org is assumed to be safe / not
backdoored.  Is this correct?

If I'm correct, is there a reason that Python is not being built in
Gitian?  Was it attempted and found that Python cannot easily be built
for Windows in Gitian?  Or was it not attempted and just still on the
to-do list?  I don't see any relevant ticket on Trac.

Thanks,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV7Mt1AAoJEAHN/EbZ1y06nL8QAM4qhFMupoippBIvI4JwlLZ6
Vf4wNWA2/IY+62DQ4hpkPRPX/vT48lJIJnPXUxQ427ruX/txYs+T8Yw/RyiW6eq8
AWrkj3DZTYE4RtgEnTazA7NEpiv0YFOuRdyKoyjZyR1MAZTWpZ12TS/hkXaksWsx
mZX7EJMv9GBNthMLGoJ5cpTdXymhbGgvOGcF1esxZlzEQnusbaMjCNHv+GzLXGBr
xEFUzjuIeuvzZxHgmTqTujjMev9kMYqpRVoyg2JbRhZz/LwbfuQssDMlTRVOmpCu
FwCw9RbyZyaBzrnoZLbJ9hs6JQz/cKYcv0kOmEncTprc6IVdZDnMj5guT0rwUycn
r9x0ZB0Uz7FRPnqIgmeHLn9JmFPuF9IWc6Kl3fILNsYMCF+AyOBAB7QVFgSftXMQ
2+ifWG6OdAZfM0jau1L6phlILJtvc79ClHhp86wIeSQ7k0mEKn9JOzEg+YRXLS4L
ZAoTFKSfNrukMtmdUhgb97yl7MA+wsdWCpMybZRpSJQYMiNlL33njG8kYMdbuhX/
uDTFmc1b3IGWhfRdAtaIK9sZzkTYTzFg30Ypr8uYte7McU+QOMHbWZGZ46KL79k7
uZxPt2bcKSzEP9KP28Pkz0Hc0v0qGYD0BrAzeYkYVB9FhLQF5vs1jDfn2YI7VQbI
HSs0NTTkxWHkro3tnzeU
=jg/n
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/07/2015 12:29 AM, David Fifield wrote:
> Way way back when pluggable transports were first integrated into
> Tor Browser, we tried compiling Python and it was too problematic
> to be worth it. Here is the comment you want to read:
> 
> https://trac.torproject.org/projects/tor/ticket/9444#comment:18 
> https://trac.torproject.org/projects/tor/ticket/9444#comment:20
> 
> Those comments are two years old now. Maybe things have changed and
> it's easier to cross-compile for Windows now. If it's something you
> have expertise with, it'd be great if you tried it!
> 

Hi David, thanks for the reply.  I don't have any particular expertise
with this myself (I've done some reproducible build work using Gitian
but it was all fairly standard C++ code), but I'm aware that the
Bitcoin wallet Armory is attempting to do Gitian builds for Windows,
and a lot of their code is Python.  I've pointed their reproducible
build specialist to this thread.  Armory's progress on this isn't very
complete yet (they're still working through bugs introduced by
cross-compiling Python), but maybe they'll learn something from your
notes, and maybe they'll be able to move things forward.

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV7OrfAAoJEAHN/EbZ1y06MgsP/ji+pb+yq5s4JgSxErv4ChRh
VXhhtmtTG4bP4IaGq0FPRcBDh6wPMQJaXxWJnRbSW/bSbb822i+IeAW9xS6+4iY9
CxocZk3L6tN4QH5yjFlLN63BzLfVCQKrlpZVHthj/98teBborVhFc4eHBS6QWN6L
dThAHIBeHt+aHi48V/QvVPzjVRptAlXqOx4KYaC+2O+sDo7ctwWNKn4iXPZ0xRDT
v+Hzj2ZXuCOsmTJrjHuz+ZfprZPRJHbIepDfvTjECjyKbN95W+JKNsj+0f+qdxau
fiJVpgKq3x7OAgD7JFx8AE7m+MaTJsr6ufb5/u5t/DfQ/x0/QopsHNGlX240BsuZ
TgeB8HgeY/5ahkoLlXkQwLTzTV9vgum65ki5IeWpv5/c1CxhaWFsAe2rMBTxnutQ
2m8+wHtybzc84jt8Ut6SmHOFvWNsnjcDgMrFMEodI6xe18FL3qNQQpq1A/NEcTIV
VGS+xLtm8rI8wgEDe/nRAz6Zj6jk3fXTXRBb94pmNAwiw6ayohtC6nzTmjsjBuDu
LYoG/ft0B/B0wOB2sxVuhtifJUiA6MGW6aHt0361oGr3qPCDEgPAX9b1YnkB6LRq
skQWJ76aDhzr56s7Awn2pO4JAORp0vnCUac93yL2Ek253TgkBKX7EczN6u/0E0AY
wjIzPkJ2ABkDjPMWUnlY
=rCHg
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 06:43 PM, Brandon Wiley wrote:
> Another option here, besides getting python to build in gitian is
> to phase out support for python-based pluggable transports. It's
> something to consider at least. Which transports are still only
> available in python?

Indeed -- the reason I originally asked this question was to evaluate
whether Namecoin (of which I'm a developer) should keep developing
code in Python or whether we should port that code to Golang.  We
really want reproducible builds, and based on the info David and
Joseph have shared, Namecoin is probably going to (where feasible)
port to Golang (which Tor is successfully building reproducibly with
very minimal code).  I'm curious whether the Tor devs have come to a
similar conclusion.

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8H+MAAoJEAHN/EbZ1y06utEQAIrpmeB7k6UDqDpmeeEdOrBB
cqKsxg28UmNo4c32+sY+ocouYBPAgqKAQwXyMkUI4sMvpPXsbWSjf8UdyXxPdcT0
JfUr/skxEf/9jfHNccHm0UfOymYeNoTsAvPTUfOxbZ2F1ZfQ49gfKzqfcntXqpKa
B3nVoQSAz8xTWeIvzJdrdZgMlNDc61Xvv4UznALJItrpGEC33RK8p4la9SwC2iss
/v/YtuqI7fPzCwzrDnQOU7ol3j40lRKhHbskTwKFBNmDp9hEKUbgQJbloiNYfXwg
cS7Q3fYM+JpPyIgJwMTV1CwTSrcF+rGLhG2gRLeCSMzKF9c8MAVCOCdpNjeKxcFx
Rc6RjWw4ClyXLyB24BrKLipd9gY0I6DWI29cEfTVKfcyHN+0qFvcecBjrFsCGWYE
RkRDVuDSRzRnIdz/kIhcxpGhezvwl09PRGCuJ8f/oLGk79QGpkqXunv2gvV9AlNM
MmIffRoEhvhqvPGf6sVx0xxphP9sk6WiCKb6n8onrQRcPVN4mPG6MjQ+eyxPOsCa
Eo+BLb78c4CVzNnhher1HeuBbR4UxZvi66V8NhcPW4pSUZamIrIxVsnwAsV70vBP
2NDfkGgpcaHVr+nr5XvccGJZWsFcYv38GlB9PuwxSNCmJI6pALQic7ArS6VMS7QZ
H8jm1cUe+2jSeFMNLiq/
=uyhm
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reproducibility of Pluggable Transports python.msi

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/2015 07:33 PM, Brandon Wiley wrote:
> I also don't know how well reproducible builds work with Go, so if
>  someone knows that would be interesting information.

Take a look here:

https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitia
n/descriptors/windows/gitian-pluggable-transports.yml

A number of Go projects are built in that Gitian script.  It looks
pretty straightforward.  (I haven't tested that Gitian script for
determinism, but I assume that Tor wouldn't be using it if it weren't
deterministic.)

- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV8NPPAAoJEAHN/EbZ1y06dcsQAICuZGa6o8xWpjXLoYLbCiVO
sPcw+GM0a5q+3JyHKOKGBhx2MVTKcB6MHrBvDzIjoUUL2J6j/5+/3mK+zwiKEaK5
JIlchn0IlzOp9XiSlLl+we2tSju9htMLYyvbpVnTMi3ebx4TyLN5VXKd9kC1ZZA0
hi8ncc1bFpld7Bo5VNPIEvM25hSKmqv9yXMrR40IYE2RiYmxQ2FbpPUMia1aqF9L
5tb0k7GnSMJ/2Pago/gQbWYKCBfdi2RK2MmqydBlqtgI43wlnizipZbNSmktpXq1
UbhbRrs8r/MOAZk9dFd+VyomKy1msBJ6c5gnY+CpWh+KSrnqnHJinZM617pH02CT
idTLxua7Z3qDuv131cUOvowKSuB2fYMMGSFxVx07UVLJMjlx/YCnjAGinQuuBwWE
K8OQ4DC+bOkZb6JcSYuntLapUQi5ukcsdFiSV6+iP82a3wCQfNbIpjq2HXQhf6em
GBR4YqtEvWCo4Ia3OYIS5RlTRSU/+Rq1cudIrtccQ26wfmz+X1jq6oUC16czp/Bb
P2rlTigxPui+lpBHYpTkvpX18UvSF3xEFSsBc9QTxsQc+gCWsR+Z11NHYzzbHhGA
qrYCnBVfhp0MePMhjoxAWRTpOQNft72RHw27WiTAd4SrekRDTiqPuuPp++7hKOoc
AwkePEMJKgkt8lrJaoVz
=BiZi
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/27/2015 05:47 PM, Jeff Burdges wrote:
> 
> This is the first of two torspec proposals to help Tor work with
> Sepcial-Use TLDs, like the GNU Name system or NameCoin.  The second
> part will be an anycast facility.   - Jeff

Hi Jeff,

Thanks for working on this; Namecoin is definitely interested in this
effort.  I have one comment.  SPV-based Namecoin clients will, under
some circumstances, generate network traffic to other Namecoin P2P
nodes containing names being looked up.  To avoid linkability, stream
isolation should be used so that different Namecoin lookups go over
different Tor circuits if the lookups correspond to TCP streams that
go over different Tor circuits.  (Also, the choice of Namecoin nodes
to peer with should be different for each identity.)  Therefore, it
seems to me that there should be a mechanism for Tor to provide stream
isolation information to the naming systems that it calls, along with
"new identity" commands.

The above issue doesn't affect full Namecoin clients, or SPV Namecoin
clients that download the full unspent domain name set.  I don't know
enough about the GNU Name System to know how this issue affects it, if
at all.

Thoughts on this?

Also, trivial spelling nitpick: "Namecoin" is typically spelled with a
lowercase "c", like "Bitcoin".

Thanks again for working on this!

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCG5QAAoJEAHN/EbZ1y06+SMQAJhN8evB2zHBqOHV8BGzQDPc
Rcwh2BXS5GDGMVoFxfTl7vyEcXf6jlHxHccbVsPihk+v5P3krDSvFggviW/+i9SU
OVg7GItivBF+QGkfe4vsmIx873/1DqNBomX6cbyisM2avLAFxOWMBHBC+Bs9dOsc
+0jT3yn7Uns0+IY8LuzgjbRVnlSrSIx7GuM8uq3fb+9OrdC/ZVgY64J4wTjFTvdi
ulrMRmQryzSC8VQ3eqqGoc0X8AytSYH54WHxwVa6gxp3tfxZ6dqfKivBUeOWpci7
+Q+q77W87GDM1VO14iRyOp69krC5RqF+vrGYlYhwmRUlpasDy+M85qigkUN0YgyP
/vVQiugkPPIyZa2QxuGrlfQ/doo1VwjY+HV0JFVkFW9tZnUsk79nhEx6R61I/AbE
KO2ttRZaWxtjPnjostVEzePywfNGKPEcq+4iRL24eY/upVRXd0wB2/99FnMhqjVG
8qk8G/Qi0EtvcgHsrxcOG44hUMv1stoHywbqcfChdKodomQMAJbPeUQ/xd9V83h4
0d1fe/Hov7MGQ0o2X007/Y9YbVfAlxjdgLSfb0qPDP/ini7jhXIixbX0raBZ5H2U
CbLrqTvf5PRWzd6lJb8wbpyo9QC1sWsR6uuqGDKypPy7d6NH8odTjAc/yXG5r7gp
YvGdrSpP45Bpp9rPZFJL
=Q21Y
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/28/2015 01:34 PM, Jeff Burdges wrote:
> On Sun, 2015-09-27 at 22:31 +0000, Jeremy Rand wrote:
>> 
>> Hi Jeff,
>> 
>> Thanks for working on this; Namecoin is definitely interested in 
>> this effort.  I have one comment.  SPV-based Namecoin clients 
>> will, under some circumstances, generate network traffic to
>> other Namecoin P2P nodes containing names being looked up.  To
>> avoid linkability, stream isolation should be used so that
>> different Namecoin lookups go over different Tor circuits if the
>> lookups correspond to TCP streams that go over different Tor
>> circuits. (Also, the choice of Namecoin nodes to peer with should
>> be different for each identity.)  Therefore, it seems to me that 
>> there should be a mechanism for Tor to provide stream isolation 
>> information to the naming systems that it calls, along with "new 
>> identity" commands.
>> 
>> The above issue doesn't affect full Namecoin clients, or SPV 
>> Namecoin clients that download the full unspent domain name set. 
>> I don't know enough about the GNU Name System to know how this 
>> issue affects it, if at all.
>> 
>> Thoughts on this?
> 
> Yes.  I distrust running p2p applications not specifically
> designed for Tor over Tor.  The GNU Name System will therefore run
> the DHT process on volunteer Tor exist nodes, much like how DNS
> queries are handled by exit nodes.
> 
> Imho, Namecoin should similarly develop a Tor Namecoin shim client 
> that contacts special SPV Namecoin clients running on volunteer 
> exit nodes. I'm working on a second torspec proposal that adds an 
> AnycastExit option to simplify this.
> 
> In the long term, there are obviously concerns about bad exit 
> nodes, especially if there are only like two exits supporting 
> Namecoing or GNS, but currently so few people use GNS or Namecoin 
> that we can probably ignore this.


Hi Jeff,

Do I infer correctly that the main intention of this is to decrease
the possibility of attack by a Sybil attack on the Namecoin network,
by making the Namecoin peer selection process have similar properties
to Tor relay selection (which is relatively Sybil-resistant)?  (And I
guess this would also eliminate issues where a Tor client connects to
a Namecoin peer who also happens to be his/her guard node.)  If so, I
think I cautiously agree that this may be a good idea.  (I haven't
carefully considered the prospect, so there may be problems introduced
that I haven't thought about -- but from first glance it sounds like
an improvement over what Namecoin does now, at least in this respect.)

The issue I do see is that SPV validation doesn't work well unless you
ask multiple peers to make sure that you're getting the chain with the
most PoW.  So I gather that this would require connecting to Namecoin
peers running on multiple exit nodes.  I don't think that's
problematic, but it would have to be taken into account.

- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCeJpAAoJEAHN/EbZ1y06h8oQAJGATJdiWg12mcRsZJ8RQeUX
mkTw+CYRMqptqt1J2PjG2g0nTIRyrwmG/coufMhPNMJBfiOKRxNvnSO/QxotUZmx
0xqzTHoaWOvNokjkGumg2J44RRFtFMPZp4/W0fpAIX820ch13f4C0RTt1qH4Asxd
PFlt/LXlVtaBHthBeAh8GNfPOmQJG0hPxLg0pP8sD2CrfvXk1VaW+dyHAvqJrPcG
CjYcgKsnzYX/FG558Kd7tfCosV95GQujMUY1AUkS7WZjU/vDXFnjZPkGjnBBOWwB
vWEYCrLMmkJWBFyTaJvdy5M39+RiXB29YlMvwOb/+dZ5QhsutU/43cP2Bi4lEqay
5ozNpDQdKEZt5Zzxs75Uad5+zEuvSg05OUEHAMgWjZQWnObnCvskWS+G2cIsgyKE
LkwntN2Njpn6UmSTQpVhakEWIcQ4n8qX6jZyw9mLxGuA4Vjlxptv40J64VvDjLri
eyokAEFO8kYtGD+3tRfj/bUjJ94q2Fb23M9Wtp93KwbhUkc6ZlZmCWtAYzNhev9e
ByjQhTcj0Y29VkS735ey0ux89FqewXR756crC63a7S2sLsU4mT8CjVcQCc+RGhbD
lcv0CbSe8zo4+RrS1yWCaPZu1sLEVKFs1m4629/zZqtusUONLNs064sfmKCa5ZZA
IAu2MwkFBJqsBi1m35nU
=WrEQ
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Special-use-TLD support

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/29/2015 07:39 AM, Jeff Burdges wrote:
> On Tue, 2015-09-29 at 00:59 +0000, Jeremy Rand wrote:
> 
>> The issue I do see is that SPV validation doesn't work well
>> unless you ask multiple peers to make sure that you're getting
>> the chain with the most PoW.  So I gather that this would require
>> connecting to Namecoin peers running on multiple exit nodes.  I
>> don't think that's problematic, but it would have to be taken
>> into account.
> 
> This is no different from validation for existing DNS results.
> Tor attempts to prevent this by building a list of bad exits, but
> it's challenging to catch an exit that attacks only one website.
> 
> You could check multiple peers but that costs you some anonymity.
> If you use many .bit names, this might expose the fact that you
> use Namecoin to your guard.

How does checking Namecoin peers on running on multiple exits cost
anonymity?  I'm not quite seeing what the attack is here.

> There are many Tor programs like Ricochet and Pond, and many
> websites, that should be detectable by a sufficiently dedicated
> guard, so that's not a compelling reason not to check multiple
> exits, but it requires consideration.
> 
> One could maybe design the Namecone shim to check obtain
> general-but -relevant information from multiple exits running the
> Namecoin client, but only obtain the actual result from one exit.
> Or maybe that's reinventing the SPV client.

Retrieving block headers from multiple exits, and then asking for a
specific domain's SPV proof from a single exit, will at least provide
reasonable assurance that the result was valid sometime in the past 8
months (expiry period for Namecoin names).  Once unspent name output
set commitments are added to the Namecoin block validation rules, it
will provide reasonable assurance that the result was valid as of
about 2 hours ago.  A single node could still censor updates from the
past 2 hours, which would not be the case if sufficient multiple nodes
are asked.

It might also be possible to download the full blocks from the last 2
hours (along with unmined transactions) from multiple peers.  This
wouldn't reveal which names you're asking for, would presumably be
only a few megabytes at startup (along with keeping up with incoming
transactions over time), and would be sufficient when combined with
SPV proofs from a single node to give you completely current data.

I'm still not seeing the attack that stems from asking multiple exits
for specific domains, though.  Can you elaborate?

Cheers,
- -Jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWCrI8AAoJEAHN/EbZ1y06e4AP/R/yJ11lHVl6L4ardFkBeUEf
yztAUkX8TWGLBTufsedA9HpF6nxfysGXAZx1HttTrdACspxF533Zzxh8lU+sN0Ak
iprJlcqkgPdxrt9XWzgLcLbk1Sie1mjAQDuPYQTFg9KEin4JuCO71JpPVhJBIr4f
8rO6tvo6XQytwEVopdxpuiJ/ZavpVWzcM2iFucD6sfpVEPGLPBAyaIxygpVI6/+Y
MzV9krQJZChCr/dUiIzM8eVDe0IzgB7QOxvGK2R4VR1PVY35sfnVJu6gS+P11R/A
QkF96auYDQ/zzuBLrrYpW0xkvxbqqSyOdWSzSuv5qP61uRNWe5l3yG4Zagx1aB+q
hvU2P8Nlz0ZKGSwqt0zk+W70DaagOsaR9swzxKKCGtl2+tXkNmbHRzsbJN/PWKP1
liXBV57uxNVg7sfbxISrg2JRCclsMWqqyAYidJBdDCxzW4FE+VmIXU5iBwbiklWr
Ge3iDdgxomuw1F4ZHs3FjC/p7rWPhQOS12Y9mM9tYyISUSzqA10ANod7TGLbMTie
xDR0zrl5vDN/8B8RJSzPsOuHApTs98tzEn6pBjj90Z0yMKDlUyLcXRTtcIIDbS9q
vwyTPGUdxkuJW23DD8EuMTl0b3ulvCivirfZyujoCk4GyFQK6CAETfcnyDa4OIHK
cfjHcgazm+Izv5eI/1bx
=n6Jn
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Go version in Gitian descriptors

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I noticed that it looks like Tor Project is using Go 1.4.2 to build
the pluggable transports in Gitian.  I'm curious why a newer version
of Go isn't used.  My understanding is that Go 1.4.2 (or earlier) is
needed to build Go 1.5 because 1.5's source code is itself in Go.
Would using Go 1.5 be as simple as building 1.4.2 in Gitian (as is
done now), and then using 1.4.2 to build 1.5, and then placing 1.5 in
PATH instead of 1.4.2 as is done now?  Have obstacles been identified
in such a configuration, or is it just that no one tried it?

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWifxjAAoJEAHN/EbZ1y0686cP/3kdRz3va8dZ056j4x9k+sd7
XJsfsj9eWJ/tPxdpppPsBIoseTVNrPSCOB/cJ/bc0Xl75KGQkHFsmGusnUp6kg9L
bwJK8wcNoO+s5EjjiY/Rk39UQTNJ3YKOaanvUnGXolYy4LtgUTTI7jdSWcpyZmd7
zxQVzvIXQEawgbu9SjTzXFkBQVHkZzkCDmTPcQNEPtIZambj7fFU0EMBWSmrYkVa
/Lzz0bq2wMcZBpdMR07JT0WcrXNgkun48gJlBCV2SuScgs+FycmQi1dVCapwptrQ
H0WeCv61XnhXTlens60gfhjrXMcUf4Xud2p71pG0N3OYrF8eOJGpSzTdnBnOFNGw
IA2B+CB8u6l8PoZAqeJg0qhFjwm/BoG9o8b8WI9WJOvqDsSfo9Mjmr2lfuoxEGI7
/Uu7aZgRboFI899/xfKJUjzZpQs3hVrtpgukjNEShDBBhsZDOQUkbfzw097NttxB
Nst6RW8WmRpbvFMGMrLiYrUKxGKJkzOUVaexU2C9y6y5asq3i2qotTmXpzEHkcP0
XL4KR9/JC6MeuBqSszEb2gpcQsHVsPxk7Wo1cJwLDSeS2YniZnxlpre5DjF2Exez
H54PqwtXTezThc8TZuTzfJZrkOA/X5ggL7/wnpUaDrF8T9r4fn1rosP6m8PdUeOL
RhVNDX3NeTjV6KywVJX4
=ELuw
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor and Namecoin

[Jeremy Rand]

lient looks up the
transaction in the LevelDB index.
4. The client retrieves the value of the name from that transaction, and
returns it to the user.

For Options A and B, if the API server is malicious, it can do any of
the following:

1. Falsely claim that the name doesn't exist.
2. Provide outdated name data that is less than 36000 blocks old (the
expiration period for Namecoin).

(Option C is not vulnerable to either of those attacks.)

If multiple API servers are consulted, and they return different
results, it is easy to tell which is lying (although I haven't
implemented any such logic yet).

The API server cannot do any of the following:

1. Provide name data that isn't from the blockchain with the most work.
2. Provide name data that is more than 36000 blocks old (the expiration
period for Namecoin).

The reason an API server is used in Options A and B instead of the P2P
network, is that the P2P network is unauthenticated and easy to Sybil.
The P2P network is great for getting data that is independently
verifiable (e.g. block headers and contents of blocks), but it's unwise
to rely on the P2P network to get unverifiable data such as a block
height of a name.  An API server is authenticated (currently via
CA-based TLS, but a cert pin or PGP signing is certainly doable), which
reduces the possible points of attack.  This is analogous to why Tor
uses centralized directory authorities -- authenticated trust points are
harder to Sybil.

(We do have longer term plans to introduce a way for SPV clients to get
the latest transaction associated with a name, without using an API
server or needing to download any full blocks, but that's out of scope
of this email.)

Options A and B do reveal to the API server which name is being looked
up.  If mode A is used, it also reveals to a P2P peer which block height
is being looked up (which narrows the set of names by a factor of
~36000).  Therefore, Tor stream isolation should be used in such cases.
(That's not implemented yet.)  Option C doesn't generate any network
traffic on lookups, so it doesn't reveal anything.

In my testing, an SPV-based name lookup using Option A takes around 650
milliseconds (over clearnet).  The vast majority of this is latency to
the API server (the server I'm testing with is on a low-budget hosting
plan).  The portion consisting of a block retrieval over P2P takes
around 98 milliseconds (although it varies by block size).  Option C
takes around 4 milliseconds.

The storage overhead of Option C's LevelDB database is around 400 MB
right now, although I believe it's feasible to reduce this significantly.

There are a few options I can think of for integrating this with Tor for
.onion naming.  One would be to modify OnioNS to call the Namecoin SPV
client.  This would concern me because OnioNS is in C++, which
introduces the risk of memory safety vulnerabilities.  Another would be
to use an intermediate proxy like Yawning's or-ctl-filter.  A third
option would be to try to get external name resolution implemented in
Tor itself, which I believe Jeff Burdges has suggested in the past.  If
Option A or B is used, any solution would need to pass the stream
isolation info to the SPV client.

Integrating this with Tor Browser for TLS certificate validation might
involve a Firefox patch.  There are tricks that can be done with the
CertDB and SiteSecurityService XPCOM interfaces that will do the job
without Firefox patches, but XPCOM is being phased out by Mozilla in
favor of WebExtensions, and I'm unaware of any equivalent features in
WebExtensions.  (Also, it's unclear to me whether CertDB and
SiteSecurityService would introduce isolation issues -- I can't think of
any obvious attacks, but I haven't thought very hard about it.)  I'm
trying to engage with Mozilla to see if we can work out a WebExtensions
feature for this, but nothing conclusive has happened on that front yet.

On the subject of reproducible builds, I've never tried to build Java
code in Gitian, so I'm not certain how difficult it's going to be.
Since Android uses Java, maybe the Guardian Project devs would have some
insight into the best way to do it.  One of the Namecoin developers
(Joseph Bisch) is really good with reproducible builds (you probably
know him since he's the author of the Debian guest support in Gitian),
so I'm reasonably confident that a way to do it can be found.

I'd love to hear feedback on all of this.

Cheers,
-Jeremy Rand
Lead Application Engineer of Namecoin



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor and Namecoin

[Jeremy Rand]

George Kadianakis:
> 
> Hello Jeremy,

Hi George, thanks for the reply.

> I'm a big noob when it comes to blockchains, namecoin, SPV clients and such, 
> so
> I'm mainly going to focus on how to integrate this with Tor.

I know this isn't necessarily needed given that this would start out as
an optional thing, but I'm curious: does Tor have people these days who
are familiar with blockchain stuff?  I know it's not particularly
relevant to the core of what Tor does, so I'd be unsurprised if the
answer is "not really", but I figure asking can't hurt.

> It seems to me that a plausible way to kickstart this big project would be to
> make an unofficial add-on for TBB that can do the namecoin dance. People can
> then install it and experiment with it. If it fits the Tor use case well, then
> a community might be formed that will push this project forward even more.

Yes, this sounds good to me.

> If it's an optional add-on, we also don't have to worry that much about the
> 400MB blockchain size, since it's gonna be optional and only people who want 
> it
> will have to download it. This way we can learn how much of a problem the
> download size is anyway (it seems to me like a total blocker for people in
> non-western fast-internet countries).

FWIW, the 400 MB that I listed is the size of a LevelDB database after
synchronizing a name database against the most recent year of blocks.
This may not be representative of the data downloaded, for a few reasons:

1. If a name is updated more often than the expiration period, the
download size will be higher.
2. LevelDB has storage overhead due to indexing, which will make the
download size be lower.
3. If an API server is used for lookups, then only the block headers
need to be downloaded, which makes the download size a lot lower.
(Hence why it takes 5 minutes to sync rather than 10 minutes.)
4. There are a number of optimizations that can be made to decrease the
download size, some of which are easier than others.  Some of the
optimizations that come to mind include checkpoints, UTXO commitments,
UNO commitments, SegVal, and DMMS improvements.

That said -- I definitely agree with you that real-world experimentation
is a useful way to learn how much of an issue this really is.  If it
turns out to be totally usable in its current form, then we can
deprioritize further optimizations, whereas if there are major issues in
this department, then we would probably want to bump up the priority of
optimizations.  In particular, checkpoints are low-hanging fruit.

> That's why I would suggest experimenting with the first two approaches you
> mentioned that don't require a modification to Tor's protocol.

Agreed.

> Specifically, if you can build a PoC with Yawning's or-ctl-filter that's what 
> I
> would go for, since I'm not actually sure what's the current state of the
> OnioNS code, and how easy it will be to plug namecoin in there. 

That's very good to hear that you suggest this, because the Namecoin
devs who would be likely to work on this (including me) prefer Go over
C++, and we already have Go libraries that are likely to be reasonably
straightforward to integrate into or-ctl-filter.

> What would be
> the procedure for third-party people with TBB to install namecoin + 
> or-ctl-filter?
> Would it be a painful UX?

To be honest, while I've examined the code for or-ctl-filter, I've never
gone through the process of installing it, so I'm unsure of how the UX
would be there.  On Namecoin's end, it would basically consist of
running a Java program; the Go library that we would hook into
or-ctl-filter will simply return a resolution error for Namecoin lookups
until the Java SPV client has finished syncing the blockchain; after the
syncup finishes, Namecoin lookups automatically start working.  So, the
UX is unlikely to be much worse than a vanilla or-ctl-filter
installation, unless there's something I haven't thought of.

> FWIW, I'm also not sure what's the state of Jeff Burdges' name resolution 
> idea,
> whether there are any plans on moving forward, and whether it would fit the
> Namecoin API.

Yes, I was under the impression that not much has happened on that front
lately.  Looks like we don't need to worry about it short-term.

Thanks again for the feedback -- much appreciated.

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to integrate an external name resolver into Tor

[Jeremy Rand]

Nick Mathewson:
> Hi, all!
> 
> I've seen a couple of emails from people looking into new ways to do
> naming for onion services.  That's great!  Before anybody gets too
> far, I'd like to send this quick note to let you know that integrating
> stuff like this into Tor is actually easier than you think.
> 
> Here's how you do it, using a Tor controller.  (See control-spec.txt
> for protocol documentation. Also see one of the several friendly
> libraries, like steam, that exist to interface with Tor over this
> protocol.)
> 
> First, you set the Tor option "__LeaveStreamsUnattached".  This tells
> Tor that it shouldn't try to handle new client requests immediately,
> but it should instead let the controller take responsibility.
> 
> In the controller, you make sure that you are watching STREAM events
> so that you find out about new streams.
> 
> Whenever there's a new stream, you check its address.  If the address
> is one that you don't want to rewrite, you just call ATTACHSTREAM on
> it, with a circuit ID of 0. (The 0 means "Tor, you figure out how to
> attach this one.".
> 
> Otherwise, you do whatever magic dance you do in order to find out the
> real address for the stream.
> 
> If the lookup operation is successful, you say "REDIRECTSTREAM (stream
> ID) (new address".  And then you ATTACHSTREAM as above.
> 
> If the lookup operation fails, you call "CLOSESTREAM (stream ID) 2".
> (The 2 means "resolve failed".
> 
> And that's it for the Tor integration!  All you need to do now is
> figure out how the name lookup works.
> 
> cheers,
> 

Hi Nick,

Let's say that the name lookup operation will generate network traffic,
and therefore should be subject to stream isolation.  (This is the case
for a subset of Namecoin-based lookup methods.)

How can a Tor controller obtain the needed information to perform stream
isolation on the lookup, prior to issuing ATTACHSTREAM?  (Subject to the
constraint that if two streams would ordinarily use different Tor
circuits, then their respective name lookups should use different Tor
circuits.)  From briefly looking at control-spec.txt, it looks like this
info is only available by examining a circuit rather than a stream,
which is problematic if the name lookup needs to be done before
attaching a stream to a circuit.

It's likely that I'm just misreading the spec, but any chance you (or
anyone else) could provide some pointers here?

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor and Namecoin

[Jeremy Rand]

Yaron Goland:
> I'm also a noob, so just to be clear, is the goal here to adopt namecoin as a 
> naming mechanism for hidden services or is the goal to enable a generic 
> extension mechanism where multiple different naming solutions can be 
> experimented with and namecoin wants to build the code to leverage that 
> mechanism so it can be part of the more general naming experiment?
> 
>   Thanks,
> 
>   Yaron

Hi Yaron,

My personal take on this is that modularity and reusability are good
design principles to aim for.  As such, I think it would be good for any
solution to allow multiple naming systems (not just Namecoin) to be used
with Tor, and similarly, multiple hidden-service-like systems (e.g. Tor,
I2P, Freenet, ZeroNet, IPFS, and MaidSafe) would ideally be usable with
Namecoin (and whatever other naming systems might be used).  Of course,
this might be difficult to achive in a completely general case, but the
amount of added code needed to add a new naming system or new
hidden-service-like system would ideally be as small as possible.

For this reason, I think using or-ctl-filter would have an advantage
here, since it also can be used with I2P, whereas Nick's suggestion of
using the Tor controller API appears to be fairly specialized to Tor.

All that said -- my opinion is that Namecoin does offer a combination of
properties that aren't really offered by any other systems, and that
that particular combination is very useful for Tor hidden services
(particularly given that the length of .onion names is going to be made
a lot longer).  So I would love to see Namecoin be adopted by Tor.  I do
understand, though, that this would mean a lot of review that hasn't
happened yet.  I'd be happy to work with Tor to facilitate that, if
there's interest.  And, of course, it's likely that my opinion of
Namecoin isn't exactly impartial, seeing as I'm one of the Namecoin
developers.  I do think that enabling people to more easily experiment
with combining Namecoin and Tor hidden services seems to be a prudent
step to take before any kind of adoption of Namecoin by Tor.

Hope this answers your inquiry -- let me know if I was unclear about
anything.

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] How to integrate an external name resolver into Tor

[Jeremy Rand]

Nick Mathewson:
> On Tue, Aug 2, 2016 at 5:10 PM, Jeremy Rand  wrote:
>> Nick Mathewson:
>>> Hi, all!
>>>
>>> I've seen a couple of emails from people looking into new ways to do
>>> naming for onion services.  That's great!  Before anybody gets too
>>> far, I'd like to send this quick note to let you know that integrating
>>> stuff like this into Tor is actually easier than you think.
>>>
>>> Here's how you do it, using a Tor controller.  (See control-spec.txt
>>> for protocol documentation. Also see one of the several friendly
>>> libraries, like steam, that exist to interface with Tor over this
>>> protocol.)
>>>
>>> First, you set the Tor option "__LeaveStreamsUnattached".  This tells
>>> Tor that it shouldn't try to handle new client requests immediately,
>>> but it should instead let the controller take responsibility.
>>>
>>> In the controller, you make sure that you are watching STREAM events
>>> so that you find out about new streams.
>>>
>>> Whenever there's a new stream, you check its address.  If the address
>>> is one that you don't want to rewrite, you just call ATTACHSTREAM on
>>> it, with a circuit ID of 0. (The 0 means "Tor, you figure out how to
>>> attach this one.".
>>>
>>> Otherwise, you do whatever magic dance you do in order to find out the
>>> real address for the stream.
>>>
>>> If the lookup operation is successful, you say "REDIRECTSTREAM (stream
>>> ID) (new address".  And then you ATTACHSTREAM as above.
>>>
>>> If the lookup operation fails, you call "CLOSESTREAM (stream ID) 2".
>>> (The 2 means "resolve failed".
>>>
>>> And that's it for the Tor integration!  All you need to do now is
>>> figure out how the name lookup works.
>>>
>>> cheers,
>>>
>>
>> Hi Nick,
>>
>> Let's say that the name lookup operation will generate network traffic,
>> and therefore should be subject to stream isolation.  (This is the case
>> for a subset of Namecoin-based lookup methods.)
>>
>> How can a Tor controller obtain the needed information to perform stream
>> isolation on the lookup, prior to issuing ATTACHSTREAM?
> 
> Conceptually, a controller doesn't isolate streams: the streams are
> isolated based on their own properties, so that's more of a client
> thiing.
> 
> One of the properties that you can use for isolation here is the SOCKS
> username and password: two streams with different SOCKS credentials
> should never be sent over the same circuit.  This should make stream
> isolation happen just fine.
> 
> [This is assuming that you use 'ATTACHSTREAM' with a circuit ID of 0,
> and let Tor make its own isolation decisions.]
> 
> Is that about what you wanted to know?
> 
> cheers,
> 

Hi Nick,

I'm looking at the docs for StreamEvent in Stem:

https://stem.torproject.org/api/response.html#stem.response.events.StreamEvent

And I don't see any obvious way to get the SOCKS auth data from that.
Using the SOCKS auth data was, indeed, the first thought that occurred
to me.

Is there a way to get the SOCKS auth data from a StreamEvent prior to
issuing ATTACHSTREAM, so that I can use that data when performing the
name lookup?

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onioncat and Prop224

[Jeremy Rand]

grarpamp:
> Hi Jeremy.

Hey grarpamp,

Sorry for the delayed reply.

> In regard your post 'Tor and Namecoin' here...
> https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html
> 
> In this thread prefixed 'Onioncat and Prop224' started and
> spanning from here through now...
> https://lists.torproject.org/pipermail/tor-dev/2016-April/010847.html

Thanks for the pointer.  For some reason I wasn't aware of that thread,
even though those messages did hit my inbox.  Probably because in April
2016 I was busy finishing semester projects and wasn't spending much
time reading email.

> Onioncat is interested in finding way to extend IPv6 addressing
> past prop224 for use by IPv6 native user applications.
> 
> There are some purely internal ideas for that. Yet to extent
> an internal tor+onioncat solution may be difficult,
> onioncat may need to develop or shell out to a non-native
> mapping and lookup layer. Namecoin has been mentioned
> among prebuilt potential solutions.

Hmm, this is indeed an interesting use case.

> Note clearly namecoin usage here *not* for human DNS style
> naming such as myeasyname.onion. But as a mapping between
> crypto key of onion (descriptor, hsdir, etc) and character string
> of (in format of) IPv6 address for use in IP / tunnel addressing.

Okay, so I've been pondering this for a little while.  There are going
to be some challenges in doing this properly, but I *think* that most or
all of the challenges are solvable with some effort.  Full disclosure: I
will need to check with the other Namecoin devs to see if I might have
missed anything, so I might need to issue corrections to these comments
if I did miss anything important.

Most of the challenges of dealing with this use case are going to be
because Namecoin simultaneously aims to satisfy 2 goals:

1. Enforce that names are unique and only updatable by the owner.
2. Enforce that names are scarce, nonfungible, and resistant to squatting.

Both of these goals are relevant for a DNS-like system that maps
human-meaningful names to values.  The first goal is relevant to
Onioncat-like systems, but the second goal seems to be inapplicable,
because (I presume) most end users don't care what IPv6 address Onioncat
assigns them, and if a particular IPv6 address happens to be unavailable
for registration, picking a different one isn't going to annoy anyone.
(If, for some reason, there are Onioncat use cases that make this
statement incorrect, please let me know.)

Some of the challenges that are posed by the existence of goal 2 include:

Creating a new IPv6 address would cost some money, conceptually similar
to registering a domain name.  This might incentivise unsafe user
behavior such as reusing identities.  There have been similar concerns
raised in the past about other use cases of Namecoin (including some
features of domain names) where name scarcity unintentionally
incentivises insecure user behavior, so I'm guessing that we're open to
the possibility of adjusting the system to solve this.

Creating a new IPv6 address is subject to a 12-block (around 2 hours)
waiting period (a salted commitment to the name is placed in the
blockchain, and 2 hours later the name and salt are revealed), so that a
newly created name cannot be sniped by someone relaying the transaction
or during a small chain reorganization.  I'm guessing that some Onioncat
users may not want to have to wait 2 hours for their new IPv6 address to
start working.  This also might incentivise reuse of identities (see
previous challenge).

Okay, so here is a suggestion on how this might be fixable.

Let's say that we create a new class of names in Namecoin.  This might
be a different set of name opcodes that have modified semantics.  In
this email I'll refer to this new class of names as MR
(machine-readable) names, and the existing names as HR (human-readable)
names.

MR names have the following new properties:

1. MR names are not subject to name registration fees.  (A fee is paid
to the miner just as would be done for a currency transaction.)
2. MR name registrations are not subject to a 12-block waiting period.
3. MR name registrations must be signed by a public key whose hash is
equal to the name being registered.
4. MR names are considered to be in a separate set from HR names for the
purpose of name uniqueness checks, i.e. registering a domain name as an
MR name is valid even if the domain name already exists, but software
that looks up the domain name will receive the HR name unless it
requests the MR name.

I think MR names would solve both of the challenges I listed, without
compromising goal 1.  Sniping is prevented because a sniper would need
to possess a private key whose public key hash is the name being sniped.
 In the case of Onioncat, the public key would be the .onion public key.

Unfortunately, this construction introduces a new issue: there are a lot
of public key systems and hash functions, and different applications
will want different choice

Re: [tor-dev] How to integrate an external name resolver into Tor

[Jeremy Rand]

Hmm, this message that I sent 2 days ago doesn't seem to have come
through.  Apologies if anyone receives it more than once.

wire...@sigaint.org:
> Blockchain addressing has some serious issues that will stand in the way
> of wide adoption.
> 
> The need for payment already makes this out of reach for many users. Lack
> of anonymous payment is a privacy challenge until Zcash comes into the
> picture.
> 
> The need to download a blockchain on embedded devices is a deal breaker.
> Battery life, storage space and storage life expectancy are tight
> constraints.
> 
> How are you going to deal with this?

Hi,

It looks like you must have missed my message that answered these questions:

https://lists.torproject.org/pipermail/tor-dev/2016-July/011245.html

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

[Jeremy Rand]

George Kadianakis:
> Lunar  writes:
> 
>> [ text/plain ]
>> George Kadianakis:
>>> this is an experimental mail meant to address legitimate usability concerns
>>> with the size of onion addresses after proposal 224 gets implemented. It's
>>> meant for discussion and it's far from a full blown proposal.
>>
>> Taking a step back here, I believe the size of the address to be a
>> really minor usability problem. IPv6 adressses are 128 bits long, and
>> plenty of people in this world now access content via IPv6. It's not a
>> usability problem because they use a naming—as opposed to
>> addressing—scheme to learn about the appropriate IPv6 address.
>>
> 
> That's true. Naming systems are indeed the way to go wrt UX. The future sucks
> if our users are supposed to use 24 (or 56) random characters as addresses.
> 
> That said, the current IPv6 naming scheme (DNS) is far from perfect as
> well. Tor would never use it (or any other system with similar threat model).
> 
> Furthermore, all the _secure naming systems_ that have been suggested have
> their own tradeoffs. They are either centralized, or they use blockchains, or
> they require money, or they require a whole network/community to exist, or 
> they
> have annoying name-squatting issues, or they require a non-anonymous
> registration, or they save HS history on disk, or their protocol is three 
> times
> more complicated than Tor itself, or ...
>   
> So it's not like we have the perfect solution on the naming scheme right now.
> We likely need plenty of trial experimentation before we decide on one (or
> multiple) naming cheme becoming the official.
> 
> We really need to start serious work in this area ASAP! Maybe let's start by
> making a wiki page that lists the various potential solutions (GNS, Namecoin,
> Blockstack, OnioNS, etc.)?

I'd be happy to provide feedback on the Namecoin section of such a wiki
page.

Cheers,
-Jeremy Rand



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Naming Systems wiki page

[Jeremy Rand]

George Kadianakis:
> 
> I made a wiki page for Naming Systems  here:
>   https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems
> 
> Feel free to start adding information and links and make it look nicer.
> 
> Let's try to build a good knowledge base that will help us take informed
> decisions. Please try to maintain some sort of consistent structure through 
> the
> document.
> 
> (In the unlikely case where the doc gets out of hand, I will try to find some
> time to curate it.)
> 
> Thanks! :)

Hello!  I just had a chance to look through the latest state of the wiki
page (thanks to everyone who's been expanding it).  I've added several
items to the security properties and drawbacks sections of Namecoin, and
made a few trivial corrections; hopefully none of them are
controversial.  (If anyone thinks I made a mistake, please let me know.)

I notice that kernelcorn added an item to the "drawbacks" section of
Namecoin, which says "Hard to authenticate names."  It's not entirely
clear to me what is meant by this item, so it's hard for me to evaluate
its accuracy.

Any chance Jesse could elaborate on this?

Cheers,
-Jeremy

PS: Happy to see that OnioNS is still being worked on -- I think it's
great to have more of the solution space explored and more options
available, regardless of the fact that OnioNS and Namecoin could be
considered competitors.  We're all in this together, and I'd love to see
both OnioNS and Namecoin succeed.  :)



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jeremy Rand]

Jeremy Rand:
> George Kadianakis:
>>
>> I made a wiki page for Naming Systems  here:
>>   https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems
>>
>> Feel free to start adding information and links and make it look nicer.
>>
>> Let's try to build a good knowledge base that will help us take informed
>> decisions. Please try to maintain some sort of consistent structure through 
>> the
>> document.
>>
>> (In the unlikely case where the doc gets out of hand, I will try to find some
>> time to curate it.)
>>
>> Thanks! :)
> 
> Hello!  I just had a chance to look through the latest state of the wiki
> page (thanks to everyone who's been expanding it).  I've added several
> items to the security properties and drawbacks sections of Namecoin, and
> made a few trivial corrections; hopefully none of them are
> controversial.  (If anyone thinks I made a mistake, please let me know.)
> 
> I notice that kernelcorn added an item to the "drawbacks" section of
> Namecoin, which says "Hard to authenticate names."  It's not entirely
> clear to me what is meant by this item, so it's hard for me to evaluate
> its accuracy.
> 
> Any chance Jesse could elaborate on this?
> 
> Cheers,
> -Jeremy
> 
> PS: Happy to see that OnioNS is still being worked on -- I think it's
> great to have more of the solution space explored and more options
> available, regardless of the fact that OnioNS and Namecoin could be
> considered competitors.  We're all in this together, and I'd love to see
> both OnioNS and Namecoin succeed.  :)

Relatedly -- I had some trouble summarizing some of the items in the
Namecoin section because the security, privacy, and scalability
properties of Namecoin are somewhat different depending on whether the
user is using a full node (downloads the entire blockchain), a FBR-C
node (receives full blocks that can contain current name transactions),
or a headers-only node (receives only block headers).

I didn't want to change the layout of the page much without asking, but
would it make sense to split the Namecoin section into multiple sections
(a section for each of those node types)?  Or is it preferred to keep
them in 1 section and say which of the security properties / drawbacks
apply to which node types (which is what I've done for the moment)?

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jeremy Rand]

Jesse V:
> On 09/27/2016 02:39 AM, Jeremy Rand wrote:
>> Relatedly -- I had some trouble summarizing some of the items in the
>> Namecoin section because the security, privacy, and scalability
>> properties of Namecoin are somewhat different depending on whether the
>> user is using a full node (downloads the entire blockchain), a FBR-C
>> node (receives full blocks that can contain current name transactions),
>> or a headers-only node (receives only block headers).
>>
>> I didn't want to change the layout of the page much without asking, but
>> would it make sense to split the Namecoin section into multiple sections
>> (a section for each of those node types)?  Or is it preferred to keep
>> them in 1 section and say which of the security properties / drawbacks
>> apply to which node types (which is what I've done for the moment)?
> 
> This is a fair point. I agree that we should split it up accordingly to
> "Namecoin (full blockchain)" and "Namecoin (thin/SPV client)". Both have
> different descriptions, security properties, and drawbacks so it would
> probably be more organized this way.

Sounds good.  I'm happy to do the split, but it might take me a few days
before I have the time to make those edits.

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jeremy Rand]

Jesse V:
> On 09/27/2016 02:27 AM, Jeremy Rand wrote:
>> Hello!  I just had a chance to look through the latest state of the wiki
>> page (thanks to everyone who's been expanding it).  I've added several
>> items to the security properties and drawbacks sections of Namecoin, and
>> made a few trivial corrections; hopefully none of them are
>> controversial.  (If anyone thinks I made a mistake, please let me know.)
>>
>> I notice that kernelcorn added an item to the "drawbacks" section of
>> Namecoin, which says "Hard to authenticate names."  It's not entirely
>> clear to me what is meant by this item, so it's hard for me to evaluate
>> its accuracy.
>>
>> Any chance Jesse could elaborate on this?
> 
> My mistake. I was thinking about authenticating the RSA keys with
> Namecoin's ECC keys, but after further thought this is not a proper
> criticism so I have removed it.

Thanks.

> Since you're checking factual accuracy of the items in the wiki, you can
> find the OnioNS pre-print here:
> https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conference.pdf

Ah, excellent, some reading material!  Much appreciated, I'll read
through that when I next catch a break.  I'm quite curious to see how
things have evolved since I last checked out OnioNS in any detail (which
would have been about a year ago, I guess).

>> PS: Happy to see that OnioNS is still being worked on -- I think it's
>> great to have more of the solution space explored and more options
>> available, regardless of the fact that OnioNS and Namecoin could be
>> considered competitors.  We're all in this together, and I'd love to see
>> both OnioNS and Namecoin succeed.  :)
> 
> Namecoin is the closest competitor. They are very different designs of
> course. In any event, naming systems should become more desirable once
> proposal 224 is deployed.

Yes, 224 seems to be making systems like OnioNS and Namecoin quite a bit
more urgently useful.

> I'm also competing with OnionBalance now since OnioNS supports basic
> load-balancing at the name level. :)

Namecoin also can be used for name-level load balancing, although I
haven't really carefully considered the anonymity effects of the load
balancing (e.g. does it open the risk of fingerprinting?), so that
feature is lower priority until I can think about that more carefully.
I'm curious how OnioNS is handling that -- maybe there's some thinking
in OnioNS's design that's adaptable to Namecoin?

Cheers,
-Jeremy




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Naming Systems wiki page

[Jeremy Rand]

Jesse V:
> On 09/27/2016 10:05 AM, Jeremy Rand wrote:
>> Namecoin also can be used for name-level load balancing, although I
>> haven't really carefully considered the anonymity effects of the load
>> balancing (e.g. does it open the risk of fingerprinting?), so that
>> feature is lower priority until I can think about that more carefully.
>> I'm curious how OnioNS is handling that -- maybe there's some thinking
>> in OnioNS's design that's adaptable to Namecoin?
> 
> Really? Now I'm curious how Namecoin does it!
> 
> OnioNS currently achieves load balancing by allowing the onion service
> operator to specify a list of secondary addresses. In this case, the
> name record contains the following:
> + RSA-1024 onion service public key
> + RSA-1024 signature
> + memorable name
> + secondary addresses
> + + "address1.onion"
> + + "address2.onion"
> + (other data)
> 
> The client will then randomly select address1.onion or address2.onion
> and will round-robin until one of them connects. It's a very simple
> scheme. Right now it looks like this:
> https://github.com/Jesse-V/OnioNS-common/blob/8217c47bce76d87d056f1bab671c44e13f1e9d69/src/records/Record.cpp#L58
> 
> OnioNS also checks that the main public key is in the root directory of
> each of the secondary addresses to ensure that they are all maintained
> by the same entity. I am still mulling over possible attacks, defenses,
> and implications, but in general it seems to work.

So, I admit that I haven't explicitly specced this out yet (or, rather,
I started speccing it out in my head, but never really finished fleshing
it out), but here's roughly what I was planning.  I was actually meaning
to ask you (and the other Tor people) what you think of this rough
design, as I'm curious if I've overlooked any attacks.

(I'm typing this from memory, so I might have a few details wrong.)

Namecoin would have 2 namespaces for this purpose: the d/ namespace
(which is used for all domain names), and the onion/ namespace (a new
namespace whose purpose I will discuss below).

Let's say that "debian.bit" is desired to map to a load balance between
"abc.onion" and "xyz.onion".

The name owner would register 3 names: d/debian, onion/abc/nonce1, and
onion/xyz/nonce2.  d/debian would include the following data (in a
JSON-based format that also allows it to include things like IP
addresses, other DNS records, etc.):

abc.onion
nonce1
xyz.onion
nonce2

So in other words, d/debian includes all of the .onion addresses that
are pointed to, and the nonces that are needed to find the other names.
Just like in a Bitcoin transaction, this JSON data is signed by the
ECDSA key that owns d/debian.

onion/abc/nonce1 contains the following data:

Onion pubkey for abc.onion
Signature of "d/debian", signed by the onion pubkey for abc.onion

onion/xyz/nonce2 works similarly, just with the onion pubkey for xyz.onion.

This has a few properties that I think are useful:

1. The human-readable name signs each .onion address.
2. Each .onion address signs the human-readable name.
3. Given the human-readable name, all of the .onion addresses can be
easily found.
4. Given an .onion address, a prefix-based lookup (i.e. not specifying
the nonce) will yield the human-readable name.  (So if a user visits a
.onion site, hypothetically Tor Browser could detect before you connect
that there's a Namecoin name for that .onion, and either automatically
redirect to the Namecoin name or give the user the choice of doing so.)
5. Since a nonce is present for the onion/ names, the worst that
squatters can accomplish is increasing the amount of data that needs to
be downloaded by the prefix search in order to find the human-readable
name.  (It would be even nicer if we could make the Onion signature part
of blockchain validation rules, but that would violate a Namecoin design
goal of being agnostic to the format of the data stored in a name.)

Revocation and/or expiration for the signatures by the .onion pubkey
could, in principle, be added to this scheme if needed, it just adds
complexity.  Expiration and revocation could both be done by making the
Onion signature also include a min/max block height and a revocation
boolean flag in the signed data.  I haven't carefully thought about that
topic yet.

The main concerns I have with this approach (that I remember offhand) are:

1. Does signing this data with the Onion keys lead to cross-protocol
attacks?  Is that avoidable by structuring the signed data in some way?
I'm not familiar enough with the Tor protocol to know for sure right now.

2. Does the use of a nonce sufficiently prevent spam attacks?

3. Will the Onion pubkeys and signatures eat up too much space in the
Namecoin blockchain?  It might not be a problem in pra

Re: [tor-dev] Proposal 273: Exit relay pinning for web services

[Jeremy Rand]

Philipp Winter:
> The proposal is in draft state.  We have several open questions that we
> are still wrestling with in Section 2.6.  Any feedback is greatly
> appreciated.  You can track the evolution of our proposal online:
> 

Hi Philipp,

It might be interesting to use this in conjunction with Namecoin.  In
the same way that Namecoin can reduce some of the issues with HPKP
(Namecoin gives all nodes the same view, doesn't rely on TOFU, and isn't
specific to HTTP), it seems like allowing Namecoin domain names to
specify exit relay pins might reduce those issues here.  Of course, this
only is helpful for services that have a Namecoin domain name.

Would there be interest in this capability?

Cheers,
-Jeremy




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

to avoid bad things?

3.4

> Does it make sense to support reverse queries, from .onion to names?
> So that people auto-learn the names of the onions they use?

After the discussion with Jesse on this mailing list earlier about this
topic, I'm actually starting to think that in Namecoin's case, it may be
problematic to expect the naming system to do reverse resolution.
(There are hacks that I discussed in that thread that could do it, but
they're unclean, spammable, and add blockchain bloat.)  My take is that
it may make more sense for this lookup to be done by the onion service
itself.  Whether this should be done by the Tor onion service protocol
itself, an extra TCP port listening on the onion service, an HTTP header
sent by the onion service, or some other mechanism is an open question.

A.2

> g) Namecoin/Blockstart

I'm not sure what Blockstart is; is that intended to be Blockstack?

Cheers,
-Jeremy Rand
(Lead Application Engineer at Namecoin)



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

David Fifield:
> So here, the browser thinks it is connecting to debian.zkey (the URL bar
> says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
> in the background. What name does the browser put in its Host header? It
> can't be the onion name, because there's no feedback from the naming
> module back to the user application layer. It must be "debian.zkey"
> then. If that is a petname, then it just got leaked to the server. I can
> imagine this might also cause a problem with some virtual hosting setups
> (though I suppose those are not very common for onion services). If the
> user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS
> name mismatch error, even if https://facebookcorewwwi.onion/ exists and
> has a valid certificate--so using the naming system is not a transparent
> replacement for memorizing the onion address. Maybe non-HTTP protocols
> will also have problems.

In Namecoin's case, that's working as intended: if Facebook sets up a
Namecoin domain name, then they should create a TLS certificate with
their .bit domain on the SAN list, that TLS certificate should be listed
in their Namecoin name as a TLSA record, and it should be served when
the SNI header asks for the .bit domain.  It's unclear to me whether
that is problematic for other naming systems.  It's also unclear to me
whether this will be problematic if Facebook wants to get an EV
CA-issued cert to cover their .bit domain name, due to the political
issues around the P2P names proposal at IETF.

I'm aware that Alec Muffett isn't at Facebook anymore, but perhaps he
would be able to offer feedback on what issues might be likely to come
up here?

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

i9nvr...@tutanota.com:
> Hi,
> 
> Why run a separate process instead of using unix socket or TCP socket?
> 
>> Since a Namecoin domain can point to IP addresses and ICANN-based DNS
>> names in addition to onion service names, and a Namecoin domain owner
>> might wish to switch between these configurations without causing
>> downtime or forcing their users to change behavior, I recommend against
>> this.  However, see the open question below:
> 
>> Open question: If a Namecoin domain points to an onion service, end
>> users might expect encryption to be built in, and this assumption will
>> be violated if the Namecoin domain switches to using an IP address.
>> However, Namecoin domains can include TLS fingerprints, which would be
>> enforced for both the IP address and the onion service address.  Is it
>> sufficient to tell users that TLS is required if they want encryption
>> for Namecoin-addressed services, or is some additional mechanism
>> needed here to avoid bad things?
> 
> How about specifying whether the Namecoin domain should point to .onion
> or clearnet in the domain?  We can require that TLDs for such service
> must end in either:
> 
> o o: The name points to a .onion name.
> 
> o i: The name points to an IP address.
> 
> o a: The name points to a clearnet domain name.
> 
> So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
> points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
> example.com.
> 
> Vina Gaff

Well, first of, using a different TLD to access A/ records versus
CNAME records would violate the various DNS specs that say how CNAME
works.  Relatedly, by your logic, why not require a different TLD for A
versus  records?

DNS, by design, allows more than one record type to exist for a given
domain name.  There needs to be a really good reason if we want to
change that.

A concern over whether end-to-end encryption/authentication is in use
would possibly be a really good reason.  But that definitely doesn't
have anything to do with whether an A/ record or a CNAME record was
used to find the IP address, so it's not a reason to treat A/
records and CNAME records differently.

It's also unclear to me that changing the TLD is the right way to
specify what record types are being looked up.  That's not the way DNS
works anywhere else.

It's also worth noting that it's been hard enough to get IETF to accept
.bit (that effort stalled) -- adding a bunch of other TLD's would
probably annoy IETF significantly (and destroy whatever good will exists
at IETF right now), and I fully understand why this would annoy them.

I'm not really sure what the right mechanism is for a user to specify "I
want this request to either use TLS or be resolved to a .onion record"
(which seems to be the primary use case here).  Does anyone have
suggestions?

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

Jesse V:
> On 10/08/2016 08:50 AM, 61wxg...@vfemail.net wrote:
>> How about specifying whether the Namecoin domain should point to .onion
>> or clearnet in the domain?  We can require that TLDs for such service
>> must end in either:
>>
>> o o: The name points to a .onion name.
>>
>> o i: The name points to an IP address.
>>
>> o a: The name points to a clearnet domain name.
>>
>> So example.zkeyo points to 66tluooeeyni5x6y.onion.  example.zkeyi
>> points to 192.0.2.1 or (and?) 2001:db8::1.  example.zkeya points to
>> example.com.
> 
> I don't think this is in scope of a naming system API. The naming system
> probably has its own rules and users should be aware of those rules when
> they use the naming system. For example, the Onion Name System (OnioNS)
> will likely use ".tor" and I enforce that names must point to either
> ".tor" or ".onion", thus keeping it all internal. During my trial tests
> today, the client code followed a chain until ".onion".
> 
> This is an API for onion services, so it doesn't make sense to handle
> clearnet TLDs. There are other and easier ways of doing that, such as
> alternative DNS roots.

The specific reason that a Namecoin domain owner may wish to have a
CNAME to a clearnet TLD is that they may wish the IP address (at the
name example.bit) to be controlled by insecure infrastructure (say, some
random clearnet domain registrar), but the TLS fingerprint (at the name
_443._tcp.example.bit) to be controlled by their own keys via Namecoin.
This is a perfectly reasonable use case: if the IP address is forged,
nothing bad happens (visitors will just get a TLS error), but if the TLS
fingerprint is forged, a MITM attack happens.

I would argue that this use case is actually very relevant for Tor,
simply because Tor exits are known to do MITM attacks with higher
frequency than typical ISP's in most countries.

That said, there's no reason I can see why an end user would care about
whether an A/ record or a CNAME record was used, so I don't think it
makes sense to have an explicit way for an end user to request that one
be allowed and the other not be allowed.

I also realize that the applicability of CNAME is dependent on what
naming system is used.  In Namecoin it makes sense; in OnioNS it doesn't
(unless I'm unaware of some reason why OnioNS would want it).  Since
it's dependent on the naming system, I would argue that this behavior
should not be dictated by Prop274; the naming system should be able to
handle that itself.  The only place where it matters to Tor or Tor
Browser is when a non-TLS connection is established and the end user
wants end-to-end encryption+authentication, in which case .onion is
okay, but both A/ records and CNAME records are not.  It's unclear
to me exactly what the mechanism should be to specify that.

Cheers,
-Jeremy



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Scheduling future Tor proposal reading groups

[Jeremy Rand]

George Kadianakis:
> Hello people,
> 
> in the beginning of 2016 we started organizing little-t-tor proposal
> reading groups in IRC, where we would discuss the current status of Tor
> proposals and coordinate on how to move them forward. You can see a list
> of previous such meetings here:
>  
> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/MeetingSchedule#Proposalreviewmeetings
> 
> Unfortunately at some point, 2016 started showing its true self, and we kind 
> of
> stopped doing those meetings in March. But they were useful, and we should
> probably start doing them again!
> 
> I went through the mailing list and found a few interesting subjects that 
> could
> benefit from group discussion. Here are some ideas:
[snip]
> 
> - A name system API for Tor
> 
>   This is a proposal suggesting a single API that allows us to integrate 
> secure
>   name systems with Tor hidden services:
> https://lists.torproject.org/pipermail/tor-dev/2016-October/011514.html
> 
>   The proposal received useful feedback in and out of the mailing list. It
>   seems that implementing the proposal as part of a Tor controller might be an
>   easier way to test it. Some discussion on future directions might be helpful
>   here, as this is something that will be needed sooner than later.

I'd be happy to participate in a meeting on the name system API.  It
might also be useful to have someone present from the I2P community, to
provide some perspective on interoperability between what Tor does and
what I2P does.  (Or for that matter any other system that might use a
pluggable name system API with similar use cases to Tor and I2P.)

Cheers,
-Jeremy




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 274: A Name System API for Tor Onion Services

[Jeremy Rand]

teor:
> 
>> On 12 Oct 2016, at 09:29, Jesse V  wrote:
>>
>> On 10/11/2016 12:53 AM, Jeremy Rand wrote:
>>> It's also worth noting that it's been hard enough to get IETF to accept
>>> .bit (that effort stalled) -- adding a bunch of other TLD's would
>>> probably annoy IETF significantly (and destroy whatever good will exists
>>> at IETF right now), and I fully understand why this would annoy them.
>>>
>>> I'm not really sure what the right mechanism is for a user to specify "I
>>> want this request to either use TLS or be resolved to a .onion record"
>>> (which seems to be the primary use case here).  Does anyone have
>>> suggestions?
>>
>> As I understand it, the spirit of the naming system API is to resolve
>> $meaningfulName to $randomAddress.onion. It seems pretty clear its
>> focused on A records, but the naming system can support subdomains and
>> CNAME records if it likes. My approach with OnioNS is to simply use a
>> none-ICANN TLD, which is currently ".tor". There's a Trac ticket on
>> which TLD I should use, but it seems most intuitive to use something
>> obvious. Someone suggested that we continue to use .onion, but anything
>> that isn't 16 chars of base32 should be resolving using the naming
>> system. That seems like it would be more confusing. A new TLD seems more
>> intuitive.
> 
> Yes, and re-using .onion would make (some) 32-character names invalid,
> and post prop-224, (some) 53?-character names invalid as well.
> 
> This is an undesirable property.
> 
> I can also imagine attacks taking advantage of this confusion.

If, hypothetically, we wanted to avoid the confusion of "does xyz.bit
point to a .onion service or an A record?" but did not want to introduce
any additional TLD's, maybe do something like:

"xyz.bit.onion" --> the .onion service pointed to by Namecoin d/xyz, or
an error if no such service exists
"xyz.bit" --> anything pointed to by Namecoin d/xyz, which could be an A
record, or a CNAME record, or a .onion record.

I suspect that most end users will understand that "bit.onion" is not an
onion service, since it's far too short to be one.

Thoughts?

-Jeremy




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[Jeremy Rand]

chelsea komlo:
> Before starting, someone today very kindly pointed me to Prop 271, the
> naming system API for Tor Onion services. Overall, my larger concern is
> whether adding the version in the onion address makes both using and
> distributing onion addresses harder. If the long-term plan is for onion
> addresses to not be used directly, then having the version in the onion
> address is completely fine as this wouldn't present a barrier to entry
> for end users.
> 
[snip]
>
> Yeah! So if the plan is that onion addresses will not be used directly
> by end users and there is an abstraction layer that hides things like
> version upgrade from end users, then going ahead with the current plan
> sounds good.
> 
> However, if there is a chance that end users will consume onion
> addresses directly, then having this discussion seems like a good idea.

Naming systems like Namecoin and OnioNS have better usability due to
being human-meaningful, but they achieve this by sacrificing the
straightforward cryptographic proofs that make .onion names secure.
This doesn't imply that Namecoin and OnioNS are worse for security
overall (I think for a lot of use cases they're more secure than .onion
once you factor in attacks on human psychology), but there are some use
cases where users will want to use .onion directly without a naming
layer.  (I also suspect that this tradeoff is unavoidable to some
extent; Dan Kaminsky and Aaron Swartz made some compelling arguments
that Greg Maxwell's proof of impossibility of decentralized consensus
algorithms also applies to Zooko's Triangle.)

Cheers,
-Jeremy Rand



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Interested in GSoC - Hidden Service Naming or Hidden Service Searching

[Jeremy Rand]

Hi Tor developers,

I'm interested in participating in GSoC.  I'm an undergrad majoring in 
computer science at University of Oklahoma, and I've been a major Tor 
enthusiast for years.


There are two possible projects which I'm considering; I'm looking for 
some feedback on which you think would be better for me to apply for.


One project is allowing hidden services to have human-readable names.  I 
think Namecoin would be an excellent backend for this.  I coded a 
proof-of-concept of using Namecoin to point human-readable .bit domains 
to .onion domains; that code is available at 
https://github.com/JeremyRand/Convergence .  For example, using this, 
you can visit http://federalistpapers.bit/ to get to the Federalist 
Papers hidden service.  The proof of concept only works on Firefox right 
now (not TorBrowser); I would definitely be interested in porting it to 
TorBrowser, improving its privacy, and making it work for applications 
other than web browsing.  Namecoin also has the useful feature of 
allowing HTTPS fingerprints to be embedded in the blockchain, which 
eliminates the need to trust certificate authorities for clearnet HTTPS 
websites (I understand that malicious exit nodes messing with TLS is 
currently a significantly voiced concern for Tor).  I have a strong 
understanding of how Namecoin's DNS works and have developed some 
projects using Namecoin (including a dynamic DNS client), so I think I'm 
a good fit for such a project if there's interest in the Tor community.  
I talked with Jacob Appelbaum about using Namecoin recently; he was 
concerned about a 51% attack.  I think that could be mostly resolved via 
a checkpointing system; while doing so adds a small degree of 
centralization, Tor is already slightly centralized, and it's still less 
centralized than other alternative naming systems that have been 
proposed (e.g. having Tor Project maintain a list of names themselves).  
While I'm not particularly familiar (yet) with how checkpointing is done 
within Namecoin's block validation system, I do know how to at least 
verify whether the currently loaded blockchain matches a given 
checkpoint (which would at least alert users that an attack had taken 
place).


The other project is making a search engine for hidden services (listed 
as Project Idea F on the Tor website).  I think YaCy could be used to 
accomplish this in a decentralized and censorship-free way.  I would 
suggest making a separate YaCy network for hidden services, using a 
regexp whitelist to only index .onion URL's (YaCy has such a network but 
I think it's currently inactive).  YaCy doesn't have whitelist support 
built in, but I think the blacklist feature should be usable for 
simulating such a feature with some effort.  YaCy's SOLR schema supports 
searching based on outgoing link URL's, so I think I could make a 
standard YaCy client search for all clearnet sites which link to a 
.onion/.onion.to/.tor2web.org URL, and feed those URL's to a Tor YaCy 
client for indexing.  I've been a YaCy enthusiast for a couple years, 
and I'm actually using YaCy in a grad-level CS project this semester 
(the course is on Artificial Neural Networks and Evolution), so while I 
haven't touched the YaCy source code, I think I'm a good match for this 
project.


Do either of these sound like good proposals?  Is one significantly more 
likely to be approved than the other, so that I know which to submit?


Thanks,
-Jeremy Rand
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Interested in GSoC - Hidden Service Naming or Hidden Service Searching

[Jeremy Rand]

Hi George, thanks for the reply.

On 03/02/2014 06:27 AM, George Kadianakis wrote:

I'd like to see human-readable names in HSes, but I'm not very
familiar with Namecoin. I don't want to discourage you from working on
this, but I'm not sure if I would be a good mentor for this.

Any idea who might be a good mentor for this idea?

BTW, I remember watching a presentation about namecoin, and it seemed
like there are still a few serious unresolved problems (domain
squatting is easy, no revocation, lightweight clients are
impossible).
Domain squatting is known to be an issue, and there are proposals to 
adjust the name pricing structure of Namecoin to disincentivise 
squatting.  While these proposals are not implemented at the moment, I 
think it's likely that they will be implemented in the future.


There is a workaround (recently implemented) for a specific use case of 
revocation: a Namecoin name can import data from a second Namecoin name, 
in such a way that one name can be held in a safe location while the 
other name would be easier to update (but overrideable by the first 
name).  So if the easy-to-update name has its keys compromised, the 
safely-stored name can recover the situation.  This doesn't solve the 
more generic revocation problem; I will inquire with the Namecoin 
developers about this.  (I think it's possible to add full revocation 
support to Namecoin in the future.)


Lite clients do not exist right now, but are definitely possible to 
build.  The UTXO lite client being implemented for Bitcoin should be 
mergeable to Namecoin in the future.

Also, namecoin are not anonymous, but people who get HS
domain names care about anonymity.
You are correct that Namecoin addresses are linkable.  I think it's 
likely that Zerocoin or CoinJoin will be implemented for Namecoin in the 
future, which would solve the issue.  In the meantime, I think the best 
way to get mostly-anonymous namecoins would be to obtain bitcoins, run 
them through a mixer, and use the resulting anonymized bitcoins to 
purchase namecoins on an exchange.  (Most exchanges don't ask for 
identification unless you're using government-issued currency.)  I think 
some exchanges block Tor, so it might be necessary to use a proxy or VPN 
between Tor and the exchange.

Yes, you seem like a good match for this project.

Familiriaty with YaCy will be very useful indeed.

On the crawler side, may I suggest you to also look into archive.org's
Heritrix crawler?  Someone told me that it's what the cool kids use
these days for crawling the web but I haven't used it myself.

Thanks for the tip, I will look into Heritrix.

I think you would be a good candidate for this project. However, be
warned that it's likely that more good candidates will apply for this
project so it might be a tough competition.
Is there a way that I could submit two proposals (one for each of the 
projects I listed), so that if there's tough competition for one project 
I can still be considered for the other?  Or does GSoC only permit one 
proposal per student per organization?


Thanks,
-Jeremy Rand
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Interested in GSoC - Hidden Service Naming or Hidden Service Searching

[Jeremy Rand]

On 03/02/2014 09:33 PM, Damian Johnson wrote:
Hi Jeremy. I'll leave the rest of the questions to George but as for 
this one, yes. It's perfectly fine to apply to multiple projects (or 
multiple orgs). Be wary though about spreading yourself too thin. 
Submitting a fistful of poor proposals wouldn't fare very well. ;) 

Thanks Damian.

-Jeremy
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Interested in GSoC - Hidden Service Naming or Hidden Service Searching

[Jeremy Rand]

On 03/04/2014 11:31 AM, George Kadianakis wrote:

AFAIK, you can submit multiple proposals. Even multiple proposals
through different FOSS projects. Like I suggested in my previous mail,
I would even encourage you to submit multiple proposals since the HS
search engine project has gotten plenty of student attention lately.

Cheers!

Sorry for delayed reply, school had me busy.

What is the preferred way to get feedback on a full proposal?  Is there 
a way to submit a draft proposal on the GSoC website so that Tor devs 
can read it and send me feedback, but I can revise it before the 
deadline?  Or should I just post a link in an e-mail to the Tor-Dev 
list?  Also, does Tor prefer proposals in plain text, PDF, or some other 
format?


Thanks,
-Jeremy Rand
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/20/2014 08:37 AM, George Kadianakis wrote:

> 
> If we are more experimental, we can even build a basic petname
> system using the HS authority [2]. Maybe just a "simple" NAME <->
> PUBKEY database where HSes can register themselves in a FIFO
> fashion. This might cause tons of domain camping and attempts for
> dirty sybil attacks, but it might develop into something useful.
> Worst case we can shut it down and call the experiment done? AFAIK,
> I2P has been doing something similar at
> https://geti2p.net/en/docs/naming
> 

Namecoin is playing around with a decentralized way of doing this.
We'd be happy to work with Tor in this area.

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJURUjNAAoJEFgMI9bDV/9qy3MH/2rf49cmo15GhVjF0nKeWQrq
2xg3waZiIRq5w9InZuRUUfpyj3vbI6GzW6sJczjf+oBB4qYEuyLji3OY4y+2nQDt
NR5pCS/FTl0O4aTf+DfYoP7rUwovbDo9lj6RzwsOwZJdFkKipvpzvs5ahxnWgiId
tP9o8l+JX+xzquVo5S1aIRo5p8clH05lQleEDP1vLxBu+8RAYmuJmFkCjnHmoa/9
78wpnVjXo4qvlKoiMuLz2LaB293aDSp29hmuorlPlUxGhE1kQVWE0eJb34MGhwKm
Bf5mFTP+dUVk0KFj83l4iUyM6yGkiWFnhAYXQIiEYtVdMtCUglWXB8wE3uHIfDU=
=xgq1
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Yan,

Namecoin would definitely be interested in something similar (we were
actually discussing the possibility of exactly this yesterday).  Maybe
we could produce a list of relevant projects that would benefit from
this?  (The three that come to mind immediately are Tor, I2P, and
Namecoin, but there may be others.)  If there are more than a few
projects that would benefit, then it might be interesting to find a
neutral format for the HTTP header, so that we wouldn't have to list
all the supported TLD's explicitly in the spec.

(CCing to Namecoin dev list.)

- -Jeremy Rand
Lead Application Engineer, Namecoin Project

On 11/02/2014 11:48 PM, yan wrote:
> +tor-dev. tl;dr: Would be nice if there were an HTTP response
> header that allows HTTPS servers to indicate their .onion domain
> names so that HTTPS Everywhere can automatically redirect to the
> .onion version in the future if the user chooses a "use THS when
> available" preference.
> 
> I imagine the header semantics and processing would be similar to
> HSTS. It would only be noted when sent over TLS and have the
> max-age and include-subdomains fields.
> 
> -yan
> 
> yan wrote:
>> Hi all,
>> 
>> Some people have requested for the "Darkweb Everywhere" extension
>> [1] to be integrated into HTTPS Everywhere. This is an extension
>> for Tor Browser that redirects users to the Tor Hidden Service
>> version of a website when possible.
>> 
>> I'm supportive of the idea; however, I'm worried that since
>> .onion domain names are usually unrelated to a site's regular
>> domain name, a malicious ruleset would be hard to detect. AFAIK
>> Darkweb Everywhere only defends against this by publishing a doc
>> in their Github repo that cites evidence for each ruleset [2].
>> 
>> What if, instead, we asked website owners to send an HTTP header
>> that indicates the Tor Hidden Service version of their website?
>> Then HTTPS Everywhere could cache the result (like HSTS) and
>> redirect to the THS version automatically in the future if the
>> user opts-in.
>> 
>> If this is something that EFF/Tor would be willing to advocate
>> for, I would be happy to draft a specification for the header
>> syntax and intended UA behavior.
>> 
>> Thanks, Yan
>> 
>> 
>> [1] https://github.com/chris-barry/darkweb-everywhere/ [2] 
>> https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.md
>>
>> 
___
>> HTTPS-Everywhere mailing list https-everywh...@lists.eff.org 
>> https://lists.eff.org/mailman/listinfo/https-everywhere
>> 
> 
> ___ tor-dev mailing
> list tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUVxzXAAoJEFgMI9bDV/9qY3UIAJrl5LI/1OHJngu1W9DsLAjr
nh+Csnm66z5tQTwiwva1Tb4b6trHv4KkHItaTm0cI44mQNsd+YEkh0oRBTSNNcRm
HY0BDn2pqTlQPN9bWvclGEtCacevCbaQiZgPpxPa+1crtavto4VAnv0/EI85QVAe
XHUNBeAHmB3qNATXsVJ61oksWlU/x8ao62fB13cUd2fVyaasWz4PPsAJ9n3TkdYG
/el7mAuM6XdA1fFaGFd1ta0jRuER2VgKQvJQctu/6a/9jiNlib3YmMOOxvF0WR+/
foUdhFkNCmRWwxqnxFDiKM0ilRLjTQ47CYRkgkqD4azPlkNvUULbO3KhaWPB9/4=
=rUsH
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Potential projects for SponsorR (Hidden Services)

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/25/2014 06:19 AM, George Kadianakis wrote:
> George Kadianakis  writes:
> 
>> Hello,
>> 
>> this is an attempt to collect tasks that should be done for 
>> SponsorR. You can find the SponsorR page here: 
>> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
>>
>
>> 
> FWIW, I skimmed the thread and collected all the tasks that were
> proposed: 
> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorRtasklist
>
>  I might have missed one or two things, so please append anything
> I missed to the wiki. Also, I haven't really splitted these into 
> deliverables so some tasks from that list might actually be very 
> abstract or very hard to do.
> 
> The idea is that in the future we will add more stuff to the list
> and then filter it to decide the future deliverables of SponsorR.

Hi,

Is it worth mentioning Namecoin under section 4, since other naming
systems are mentioned?

Cheers,
- -Jeremy Rand
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUdQwxAAoJEFgMI9bDV/9q6vwIAJ6A+dpwA9E7kBu32Hdp3kkA
ljJX667aya7k+pggo+ZHwUwWOn/W7WyWXbWgQ7fKco1qknzslETNfRislNJGviRd
ZJGZxR1WUM2plnkzxxmyZASrrUfXksBgdJWIgfVWRfmf8LZL3XWB/zg9f5aP0Soq
3JhuDbeOsy8UA1jpL3bO5W8+WXe5YfZQ4j6oUMQFKQyeBX7O6QgLzqy6OkJkW5h1
Cq0opUZY0smKsu/BPf3Mdfp05+am0q0i3pAelEnLiodYDFbxUgxI6GTbVOY7iqy7
rvrfjJcdlhYHM09mlhKZp5GoErOCko9iJZQQ4wv2IAr9uX5aFIlr5qbIbhFebqc=
=4akL
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Of CA-signed certs and .onion URIs

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/2014 08:37 PM, Jacob Appelbaum wrote:
> On 11/15/14, Lee  wrote:
>>> c) Get .onion IANA reserved
>> 
>> It doesn't look like that's going to happen.
>> 
>> https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/
>>
>> 
is expired & I haven't been able to find anything indicating it's
>> still being considered.
> 
> It's still something that we're working on it. We should update it
> and post a new revision. Seth Schoen recently went to the latest
> IETF in Hawaii to discuss it with some folks in person and we're
> going to update it after we review his feedback.
> 
> All the best, Jacob

Good to hear that it's still being worked on; the Namecoin guys were
getting a little worried that the current public draft had expired.
Looking forward to seeing a new draft.

- -Jeremy Rand

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUew5tAAoJEFgMI9bDV/9qnoAIAITWbvkdvRQYoN/zGsQWU6oJ
ZeSODjEU8w6p4sgS9yr6poDWNUDWL8cei9kWFvsRN5mXfZqMu8vABVqRlDhQ3LRn
Yn6Q13m3Rr9M7J/ZhJJ2tvVa9ZZ8j9GoaMbAlBf8MG8Ou2qqhWvvDkEI+be6oMAe
ure3bojHnEcBa60hnQrF6sWAwaT3sORr+KmUiThe7AG90hyEgK4VzOjB/IMEyLVZ
bBCnFcV1oMTSoYJp+F4Gpp/ya1wQRs6EvsMp/47F4bhUV1r64CeY/FssFALYLShu
MrM4UQOdyRpiDuH/AeK9R8yywe/mrtr0QCvr8oxIR8KWsJadpVjs4Zv0i0xrbzI=
=XiwS
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Tom Ritter:
> It seems reasonable but my first question is the UI. Do you have a 
> proposal?  The password field UI works, in my opinion, because it 
> shows up when the password field is focused on. Assuming one uses
> the mouse to click on it (and doesn't tab to it from the username)
> - they see it.
> 
> How would you communicate this for .onion links or bitcoin text?
> These fields are static text and would not be interacted with in
> the same way as a password field.
> 
> A link could indeed be clicked - so that's a hook for UX... A
> bitcoin address would probably be highlighted for copying so that's
> another hook... But what should it do?
> 
> -tom

Bitcoin has a URL scheme that is increasingly used, so the UI
mechanism could be the same as for .onion links.  However, for both
.onion links and for bitcoin: links, there's a risk that the website
will simply ask the user to manually copy the .onion URL or Bitcoin
address -- I doubt that most users will recognize this as an attempt
to evade detection.  So any UI mechanism will probably need to
recognize any string that looks like a .onion URL or a Bitcoin
address, even if they're not links.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY4GYXAAoJELPy0WV4bWVwz60P/2cOYAiRLaTx5wjy+pyqQCUn
N4+mZv9+YmW7OiqJKEylywyTcdhLeAAVlQPafawvN+9K1EObqiF5GtHdHOaOE+EJ
43iUbpRzMsZOlPGspP6YUrJw6zjLev021qMyyZv1r0EMPgi3d+jbfvrgPHcgw7AD
aA5hDy1bVAoLovwIWL1w/62MK+gsMHroE3oDOYNI3i6uLJHVtsdTdCVit8rwshey
BKOBY0xgh2pvMDGwB4hdK4K0GHAUcef6ErDXhrpKFPDjuJnLi6g5i3oPbgaI9YuR
ONIb3eK2K81oblpEmRxQgEJHby7sMKfqRqpsabcTDn6WUlN0z91JTqRtJWvyZYYC
rabdeLrEqlOA7IGG7S4w3hUlWi7Ql/iwUM3/9b3SNztwcWrC/VmCjDPpiZ/aJpI9
QP5/Y2SC5TYQ0+DRLe3HynI/zc5WHpRW6TU570BnJc+V5Y1uf8GH2g6WMNRegTKm
++cCx2SLGn2CaqHCubos7FVtx2Yi443vlL9kNE1bgsZIZBa8PGx6m3MjpZ8K9NLt
e1HkTbCGQaB09pVvMMRiazqc6r3sJcvogcmdct21P6ElyEW4D9L+grWqESNSM+gm
mlAIrMsfYeZnpl7vgmKVQ2TqirCxvLMA0movYjhISkyKIsPTSHc8Qoc00WHt2MvX
lus5voupc4tmsDtB/8z0
=L3v2
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC: Support all kinds of DNS queries

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Daniel Achleitner:
> Hi everyone,
> 
> I'm a Software Engineering master's student at TU Wien, Austria, 
> with a recent focus on computer security and privacy issues. I am 
> interested in participating in GSoC 2017, particularily in the
> task to support all kinds of DNS queries via Tor [1].
> 
> I've seen the mailing list discussions of 2012 and read the 
> resulting proposition 219 [2]. What do you think, which parts of
> it (if any) would need to be adapted for DNS in 2017? My current 
> impression is that not much has changed, particularily regarding 
> DNSSEC support and deployment.
> 
> As of now, the proposal looks fairly complete with few questions 
> remaining, the biggest research task being how to utilize 
> libunbound for query/response parsing and construction. 
> Implementing the RELAY DNS cells then seems fairly
> straightforward. Unit/integration tests and some fuzzing would be a
> good idea. The problem of reducing DNSSEC roundtrips
> (serialization) to be investigated in a later phase, I would say.
> 
> Is a separate AXFR tool still something that is desired? I have no
>  experience with zone transfers -- can't the existing tooling just 
> be used over a normal TCP conn through Tor?
> 
> This project idea would make a good match to my thesis in
> progress, for which I am researching and evaluating
> privacy-improving DNS tools in the context of Tor (DNSCrypt,
> DNS-over-TLS) [3], inspired by the awesome paper on DNS correlation
> [4]. For example, I recently built a SOCKS-to-SOCKS translator
> which allows to resolve hostnames using a resolver of choice, e.g.
> using DNSCrypt with TBB.
> 
> Looking forward to hearing your thoughts, concerns and opinions!
> 
> Best regards, Daniel
> 
> IRC handle on OFTC: idealchain

(Thinking out loud.)  It would be interesting to have some kind of
algorithm agility here.  For example, a Tor client could send a
request for a Namecoin domain name, and the exit relay would return a
Namecoin merkle proof in the same way that it would return a DNSSEC
signature if were a DNS doman name.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY4G6EAAoJELPy0WV4bWVw2UMQAKEbpa5u0zHHHAYrZS5huMcM
LsCmd5o1q5fQXzVyncWiYVasYUUQHcMp7SygqLJK6mCNgvDgytYGQ6S9qbt/xnqO
aPxIBBM0zYEnmn2QMg35AxjV8P9uc0TuAHpfA03shlD8adgRqSsUocYjeI2fa0P4
ZxggtLhPXrk3CHJqfKL1gwr/+fSFTS7MrXc9HnnmwCUaB3h+5tggMjEXeQxjsfES
mdgL/Y9ecQD+k+dxtuWoTFrqoOLE1Asa8Ve1dGo4hUSyD6MkPKnjj2wQKAditj+w
zXB1ETd0ZQEKX/mguZXff9596AJklDRsU+HTKplNJsyh/nkqpL05PKeaaQerSynf
5bgc2Z4U4eHenMvnh4QGq+Ce9xuS+8moSfU218GLilJz1jz2K5P9YxLG2KFl3Bhu
O99merBZbBxgGpism/C/Ae9GgtH20pvgKeN/rgy+80DbowF5e+m+9qH/DXoKArIu
+u1LYHM4dT02VHONy2y31RS8maWebsm6tWQ4ciit2vRg2dukzzDmQQt/Wj6L2pal
4o24cp6CsIU/kifb/gEYYE5id4mbr1u580jXFvMeTrWRMvRp1o6uxFaaV4GtY1OG
VTCuQuuuEXysA8I0+SYpVnAyM6zoq/mJkZGhl/doRgMdn7RA5XEJHrxsE5z8PYTE
vl/kcBsLKuO6EKxJ8TAt
=Ctku
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Prop279 and DNS

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello!

Maybe this topic has already been brought up, but in case it hasn't,
I'll do so.  I notice that Prop279 (onion naming API) defines its own
API rather than using DNS.  I guess that this is because of security
concerns about the centralization of the DNS.

However, in case you're unaware, Namecoin is designed to interoperate
with DNS.  Let's say that, hypothetically, Tor defined a DNS-based
naming system for onion services, where "_tor.example.com" had a TXT
record that was verified with DNSSEC in order to make Tor direct
"example.com" to whatever that TXT record had.  If this were done,
Namecoin would be able to produce the necessary TXT record and DNSSEC
signatures, via the standard DNS protocol, using an authoritative
nameserver that runs on localhost.  (The DNSSEC keys used would be
unique per user, generated on installation.)  Indeed, this is how
we're planning to interoperate with non-proxy-based Internet
applications.

My guess is that it would be a lot less work on Namecoin's end if such
a system were used with Tor rather than a separate naming API.  It's
unclear to me how this would affect other naming systems such as GNS
(does GNS interoperate with clients that use DNS?), and it's also
unclear to me whether this would produce extra work for the Tor
developers (maybe DNS adds extra attack surface that would need to be
mitigated somehow, or maybe there would be complexity in implementing
stream isolation?).

Anyway, just figured I'd bring up the topic so that everyone's on the
same page regarding figuring out whether it's a good idea.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY4rf2AAoJELPy0WV4bWVwviQP+wSz9/L8czef+L+viSIIrrtv
BOp32fysFWw1HijQ/42IoELPhkkzsHjek4IuW6Hn3VHGYs9vJ+rQ9aOcCMGNGD/f
f7ktcw3upH/UHiFPp2S0LeNqaoup8qvUQxG/AeP5R20gD/660ZXuIVl4uOaOu5HJ
IaghO9ZpzSF695H97hf7bz3H3Wrmch8tjC+FZ+SwWdgqGa4ijjZbTvkypcPEZ6YI
YQ22PmoQQWQBbe9JLujLa46PwRWU+UKsppmQYi7dY9K7aO7/J9eKQnOLkUWtdKrN
WjtJMV+V4oL/g4IiJrPs5n82pGSvpFi/dMrakoGq2w+v1dJolz/lSGUj7+sWVQZl
iqoq6c+l7MjKNynmj/Yn8IquhhwRmVAj4sjV+2jUeVmAf/tHDCBsDYvIDcDeIblu
j6y9e7ePTlMTpuxbZ7OKJjsWgGF5+yumWHPtJYs9uBoATeYDM6+Gxm73rDZxRVCl
+KGN1jMuREA9N1ZiWuK/ueeeZWGHii4L4UWvdK0qriSvc0HxaQeCGlovEDfO8btO
ZDfq9P6USEZywqFyzjzvOUwxnhihwNMdFiSt0RfxLuX34H6POvFYHhw85ESlliY8
0RPjHW6GZywNuOgpYDu9kPS6HPFhXUtok708Jmc926ctX2TT0CJlK6Fl3R2kZGCa
nOLHLSYVmkehj6u3RdBf
=Hz3g
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Comments on proposal 279 (Name API)

[Jeremy Rand]

 behavior much easier to understand and explain.
> 
> Let's require that the TLDs actually begin with a dot.  (That is,
> I think that ".foo.onion" can include "bar.foo.onion", but I don't
> like the idea of "foo.onion" including "barfoo.onion".)

These make sense.

> Section 2.3.1:
> 
> Does the algorithm apply recursively?  That is, can more then one 
> plugin rewrite the same address, or can one plugin rewrite its own 
> output?
> 
> (I would suggest "no".)

I can imagine some use cases where a Namecoin name wants to delegate
to an OnioNS name or something like that, but frankly I'm having
trouble thinking of a reason why anyone would actually need that, and
I can imagine users being confused when encountering something that
looks like a Namecoin name but actually has security properties (and
technical requirements) derived from both Namecoin and OnioNS.

I can also imagine some use cases where a Namecoin name wants to
delegate to another Namecoin name, but the extra complexity of
handling that use case inside Namecoin seems to be pretty minimal.

So I think I agree.

> I think there should be a way for a plugin to say "This address 
> definitely does not exist" and stop resolution.  Otherwise no
> plugin can be authoritative over a TLD.

Strongly agree.

> Section 2.5.1:
> 
> Is the algorithm allowed to produce non-onion addresses?  Should it
> be?

See my comments above.

> Section 3.1:
> 
> I prefer the "put everything under .onion" option.   I also think
> that we should require that the second-level domain be 10
> characters or less, to avoid confusion with existing onion
> addresses.

Curious what the criteria used for choosing 10 is.  Certainly 10 is
sufficiently small to not be mistaken for a v3 .onion address, so I
have no objection here.  (I note that len("blockstack")==10, which is
the longest name of any of the candidates I'm aware of -- would that
be why, or coincidence?)

> General questions:
> 
> I know we've done stdout/stdin for communication before, but I
> wonder if we should consider how well it's worked for us.  The
> portability on Windows can be kind of hard.
> 
> Two alternatives are TCP and named pipes.

Been a long time since I messed with Windows and pipes, but last I
heard Windows's implementation and API for named pipes has almost
nothing in common with POSIX named pipes.  Is there an abstraction
layer for this that I'm unaware of, or would Tor (and the pluggable
naming systems) be responsible for implementing this abstraction?  Do
such abstractions exist for all the languages that pluggable naming
systems will be using?

> Another alternative might be just using the DNS protocol and
> asking for some kind of "ONION_CNAME" record.  (DNS is ugly, but at
> least it's nice and standard.)

I started another thread about this, so I won't duplicate that
discussion in this thread.

> Security notes:
> 
> I'd like to know what the browser people think about the risks here
> of (eg) probing to see whether the user has certain extensions
> installed or names mapped.  Maybe .hosts.onion should only be
> allowed in the address bar, not in HREF attributes et al?

Does Firefox have a mechanism for applying a same-origin policy to
everything that a web page can invoke (e.g. images, which aren't
affected by the same-origin policy by default)?  If so, maybe it would
make sense to apply such a policy to each naming system, so that only
Namecoin websites can embed images from Namecoin websites?  Maybe a
NoScript-style manual whitelisting UI could be used for this?

Non-global naming systems like GNS are likely to need additional
protections, I would guess.  It's not clear to me how much protection
we can enforce without annoying users too much.

> We might want to think about cache-related timing attacks here. 
> Perhaps we should have a "no caching" rule.

Totally agree in theory.  Namecoin may have some trouble following
this in practice since our SPV client is in Java, which has an
extremely long lookup time for the first few lookups after boot due to
the JIT warmup.  This doesn't reveal *which* names were previously
looked up (at least, I doubt it would), but I can imagine
fingerprinting attacks that detect a Namecoin client that hasn't done
many lookups since it was last rebooted.  Not clear to me how much
damage this can do in practice, but caution is warranted in the
absence of evidence.  Maybe looking up a few junk names immediately
after initial boot would be sufficient to fix this.

> We should probably add a security notes section for how to write 
> plugins that aren't dangerous: a bad plugin potentially breaks
> user anonymity.

Strongly agree.  Even though I'm reasonably fa

Re: [tor-dev] GSoC: Support all kinds of DNS queries

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Daniel Achleitner:
> On 2017-04-02 05:22, Jeremy Rand wrote:
>> (Thinking out loud.)  It would be interesting to have some kind
>> of algorithm agility here.  For example, a Tor client could send
>> a request for a Namecoin domain name, and the exit relay would
>> return a Namecoin merkle proof in the same way that it would
>> return a DNSSEC signature if were a DNS doman name.
> 
> It certainly seems to be a good idea to design the cell format to
> be agnostic as to what kind of "proof data" is attached to the DNS 
> response. As prop219 just wraps around the existing DNS-packet 
> wire-format, it should already allow that, provided that Namecoin
> has a wire-format for the proof.

Awesome, that's great to hear.  Namecoin doesn't have a "canonical"
wire format for those proofs, but we have one implementation that made
up a format for its own use (with the intention of standardizing later).

> Certainly out of scope for GSoC, but I'm wondering: Apart from
> running a full Namecoin node (and storing the whole blockchain) on
> every client/exit node/whatever, is there a privacy-preserving way
> to resolve a .bit domain, i.e. without an upstream node/resolver
> learning/logging exactly which domain was resolved?

I can think of 3 ways.

(1) We have a client right now that only downloads the full blocks
from the most recent year (which means it has all the transactions
that correspond to unexpired names); it also downloads the block
headers going back to the genesis block (so that it can verify PoW).
This requires around 10 minutes to do initial sync, and around 400 MB
of storage.  This client generates no network traffic for lookups, so
no one learns anything about what was resolved.

(2) It should be possible in theory to do a softfork that has a
coinbase commitment to a merkle root of all the unexpired names and
their values.  This merkle tree could be constructed such that you
could retrieve a subtree from another Namecoin node, and verify that
all the names in that subtree are authentic, while not revealing to
the node which name within that subtree you were looking up.
(Choosing the tradeoff between subtree size and privacy is up to the
user.)

(3) We could, hypothetically, hardfork to store only the hash of a
name in the blockchain rather than the name itself.  The value of the
name could be encrypted with a key derived from the preimage of the
hash.  This would hide the name being looked up unless the node being
queried already knew of a specific name or hash to be looking for.

I don't foresee (2) or (3) happening very soon, but maybe in the future.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY5uamAAoJELPy0WV4bWVwfCUP/3aHWVoqiA2/ClnHFeogIftP
xD8iUX+c8+vpy9IwqSnF/UUVg2Sg6tlJ1RxebrCO2CvBRGXWVZyBQoGWSWrTwIcC
1QIfXqGrTU7dBJzk578Rwz4K6TaqblWpDIJQ9dV0FwMttighVD62jaDiJiFqqmVN
TLFBjHBSanyxqnZ4g1fWS0baKVnzR2TgpaJiTaHNDhqv/FCKeR4Gnj3mGuxreO1z
w7FrvFYSF9esCcqYtMB0zkPFyXbuaYg2tinnlx6TdmzhsLIMHIZVOlVbY32CFeee
ZM3q9gogX0581rNF5oVfSxDVnD99n+1GMYpmpWoq0dQEnrK4AQoLumXqmlFmEr/6
85pNcm+gETs0TH3vT8Cnbkc5tchd0wejLOdGFFjQgPu6iIcHQy8bd1xAyWIO2Ygl
6dbuOvc72vCoqc2HuM0cRkJXqnToiZHtJx5jdRYImFMubWqLaVVB4shkHMCVUBGm
7FySsjWYU4vHsD74R8mrT79Gde3vOpqVFdsJQMoYAojWLk2Vzn9/wC/DayMDyO//
PKm2ET3iYefLil/fo1s7+JuAAUco1vGNvLkOf+0/3PTGsWi7QbWAOznvykOd6OmT
ap+rRdQfGTvEc+/m1q4fTCyRL/EaSyxNNgYBjKFfHyLHZJqP/CLXG49lruuQr9sH
9tJ8BCGpH8tEDHJUZb3l
=tnyY
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Prop279 and DNS

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jesse V:
> On 04/03/2017 05:01 PM, Jeremy Rand wrote:
>> Maybe this topic has already been brought up, but in case it
>> hasn't, I'll do so.  I notice that Prop279 (onion naming API)
>> defines its own API rather than using DNS.  I guess that this is
>> because of security concerns about the centralization of the
>> DNS.
> 
> Hi Jeremy,
> 
> I believe that the general idea with prop279 is simply to introduce
> an API for resolving pseudo-TLDs before they were sent through the
> Tor network. How that is done is entirely dependent on the naming
> system.
> 
> For example, if a user typed in example.bit into a Namecoin-enabled
> Tor browser, the software could then perform your proposed DNS
> lookup and rewrite the request before turning it over to the tor
> binary. In my case, my OnioNS software rewrites .tor to .onion,
> since the tor binary knows how to handle .onion. At the moment,
> this is a bit hacky because the software has connect with tor's
> control port, manually review and process each lookup, rewrite the
> the request, and then tell tor to connect it with a circuit. Prop
> 279 is designed to make this much easier and avoid hacky
> solutions.

Hi Jesse,

Yes, I understand that the goal is to provide an abstraction layer for
naming systems that doesn't rely on control port hacks -- and that's
great!  My primary inquiry here is about whether the DNS protocol
might be a better-suited protocol for Tor to use for talking to naming
systems, rather than a Tor-specific protocol as is proposed now.  I
don't hold a strong opinion on this; I'm mostly just curious whether
it was considered, and if so, what led to the decision not to use it.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJY5wi/AAoJELPy0WV4bWVwp78P/jd8xte9hgEZiVIJ1nSgIV7Q
Yo3NNZpSlDyeyPr2XktGm9JUsBGgMjN+D+oIQcilEiaIAuufrdNW8R4n00VoJMgQ
yAHB42UNRJXq1W9+Y7TgrDHjbzsea4fNSZSA5e2kHqOaxPV5fK/qX7xKC8/fPHsf
329qk8BPcGVe2SkLkJqNKBW5D5cBA54HcMENV6w/6Vos64OD/ZKUOclSHcubtwWz
kYRn6ERv67/dHRV8M58WYewA/lFvyvMCSLyyZbfJXuJEsV6wlpFIxWbJezps80EU
coiCunGeu0TCj6Ae0lVtr8cuyMCN4WyCs7C4BkdiuCrLwri+IW8vR8LeP8fLjQCa
ImnfgxIOdxiHti77UPzWjEPGKerdJi/gVF4NmJ2XL2qJEv0rr4hnaEn3LKTHAEQm
0k0EjDXGaMgNhSS5y67PLW5bW909uISrCIYnNAOfSi3vRwCfYusY3N0P6seH78R9
VNhS/bnUCTEfD3CJFvZD2coUbpvG/vXW5OI8D02Ro+3FJqvcbbkXXhimK0d9R65V
s96ckSAmI+m0VD7FO3hGW0BUzGdzVAJIsEfLIwUCqasQ7ugwbawfh0JvjYreM14T
ZmnM9usdNPcgE+uRnZbHpHG6n3GcOIWc1ShhoCHvzaF3zF8+UWPMElwmFA4XZCo2
2YgPFCAuFfSfQapZxrX9
=iXyt
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Experimental Namecoin naming for Tor

[Jeremy Rand]

Hi,

I've pushed some experimental code for using Namecoin naming in Tor.

The code is at https://github.com/JeremyRand/OnioNS-client , you want
the "namecoin" branch.

Rough instructions:

1. Install Namecoin Core and let it fully download the blockchain.  (SPV
support is in the works.)

2. Enable JSON-RPC with user/password authentication in Namecoin Core.
(The procedure is identical as in Bitcoin Core.)

3. Set your Namecoin Core JSON-RPC login info in the init_namecoind
function of src/assets/onions-stem.py.

4. Start Tor Browser Bundle.

5. Run src/assets/onions-stem.py.

6. The first time you run it, it will instruct you to add a line to one
of the Tor config files; do this.  Specifically, it will ask you to add
the line "__LeaveStreamsUnattached 1" to torrc-defaults.

7. Start Tor Browser Bundle again.

8. Run src/assets/onions-stem.py again.

9. Try opening a Namecoin website in Tor Browser.

Example websites that I've verified to work include:

http://duckduckgo-onion.bit.onion
http://bitcoinpl.bit
http://federalistpapers.bit.onion
http://botball.bit (gives a Dreamhost error)

The .bit.onion sites should also work as plain .bit.

Semantically, .bit.onion means that it will always resolve to a .onion
address (meaning that .bit.onion names are encrypted and authenticated
regardless of whether TLS is used); .bit means that it will resolve to
any of .onion, IPv6, IPv4, or CNAME (prioritized in that order), meaning
that .bit names are only encrypted and authenticated if TLS is used.
These semantics are open to revision later, as the Tor community evolves
its canonical naming semantics.

This is all proof of concept for now; some or all of this code will be
rewritten later (hopefully to use the pluggable naming API instead of
the control port).  It will probably not work with Whonix/Tails/Subgraph
due to the control port filter.  It will definitely make your Tor
Browser instance stand out, since most users can't resolve Namecoin
domain names.  And since it accesses the control port, it could
presumably do lots of horrible things to your Tor instance (and I make
no guarantees that it's properly sanitizing the input that's passed to
Tor's control port).

Huge thanks to Jesse for OnioNS (on which this code is based), and also
thanks to Nick for sharing helpful info on this mailing list.

Let me know how it works for you.

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Prop279 and DNS

[Jeremy Rand]

or Tor send that merkle proof to
Namecoin for validation.  I have no idea whether this functionality
would also be useful for OnioNS and GNS, but I guess that it would be
beneficial for DNSSEC.

Anyway, I don't have a strong view on whether using DNS as the
abstraction protocol is the right choice -- but it's good to have the
discussion, I think.

Cheers!
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Prop279 and DNS

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hugo Landau:
> After giving it some thought, I think Tor should use a
> Tor-specific protocol to interface with name plugins, not DNS.
> 
> My reasoning is as follows: the Tor daemon knows what it wants and
> is designed to source specific data from a name plugin. Where Tor
> specifies a custom protocol for this, this will match perfectly the
> type of queries and type of responses which Tor needs to ultimately
> obtain and convert to some corresponding internal in-memory
> representation.
> 
> As such, forcing this made-for-Tor format to be marshalled into a 
> pre-existing format, namely that of DNS queries and responses, can
> only ever reduce the power and flexibility of the plugin interface.
> It only creates the potential for impedence discontinuities, and
> also creates a substantial nuisance and implementation barrier for
> plugins which are intended only for use with the Tor daemon. These
> plugins would need to source a DNS packet marshalling/unmarshalling
> library, which creates an unnecessary barrier to implementation,
> and both sides of the interface would be marshalling into a format
> which isn't especially aligned with the internal representations
> they'd ideally like to be speaking. As such, using DNS here feels
> rather pointless.
> 
> Looking at the Prop279 proposal as it stands, it would be trivial
> for a plugin that wants to work with DNS packets to convert a query
> to a DNS packet. As such, I see very little utility to adopting the
> DNS format for this.

Thanks Hugo.  Yeah, I think you're probably right.  In Namecoin's
case, it *may* make sense to have a Prop279 provider implementation
that uses DNS to talk to Namecoin software, but the difficulty of
doing stream isolation properly with DNS and the rather large set of
DNS features that have no relevance to many Prop279 providers suggest
that it's unwise to force that coupling.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZBDotAAoJELPy0WV4bWVwyCgQAIinmd5pBqf86vq4ae2N9KwX
/IFstwBZFuD7QSzBeFyQI1n+tP76OHM7dSpPPvZZfz8ksuTLwjdYJBkSDMGoiWzS
KjAFcFK4VBCmPhkq6nd97nqSYXiqlyoZMKCAwE6Yxg4YV6a0mLnfkNYdIpRwXgXa
EkL75FxsYFFWPztLBa63vZlJcuxfJ4lBtZDdhiRunnQh+KXwHmA2fukc8yqxs5lF
tnE2Mzb06bI3KYmcjmpi+Zb0u2QYNtnY5jPTN5LNu4XeOcpvKieHpqEDHTBVzArR
3zXpmvmvWlPcT6KzWp4kaNM+f76Q/uXbetVfyPPPUlxR3fKbRGjJ9owpGpcR/Nhb
YnpG0jSZXKu5j+zN9mXM+SB+lBVqOGwwF5ae2oIRe6H0gG53il7jv3gQCSh/EZO7
9harqftv9LqfKtPZpRjzIWGv2DSriy2wPJsKwsL1o3c/DrEbnbbh/cEIs+RMlijF
fjP2daO9DVKnAClB8YcZw0cgWc4xZ5EcZnF0FPsV4ZWREgG1UIzUm+fV04HPruYB
k5OX5T4HdNSU0lJJY7H4P6VHbpr3i73PnDBJsUvOM2cFQattxGCMxGzF5pDp+wIC
R2dFLASWtiQOL4alyqUxP9aoR7DJcvYm7jThe1aNjyyN880wbYCJnUYEoQa0k10t
DBAecAT+HDKuZt7WklMm
=84wv
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Names for your onions

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

heddha:
> A friend and I are looking into implementing a few of the ideas
> listed in [0] as part of a university project. We saw quite a lot
> of discussion on idea 1, but we're mainly interested in working on
> ideas 2.5 and 3, and additionally either 2.1 or 4. Has there been
> discussion and work on these yet? Where can we find it? Is there
> anything else that you can tell us that we should know?

Hi heddha!

I recently made a proof-of-concept implementation of Idea 4 ("Embed
onion addresses in DNS/DNSSEC records").  Some information about my
implementation is at the following links:

https://www.namecoin.org/2017/06/21/tor-prop279.html

https://www.namecoin.org/2017/06/22/tor-prop279-release.html

https://www.namecoin.org/download/betas/#dns-prop279

https://github.com/namecoin/dns-prop279

Admittedly the documentation is pretty weak at the moment (and it
hasn't gotten much testing), but maybe you'll find it interesting.
Feel free to play around with the code and/or ask questions and/or
submit bug reports/patches.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZTxSUAAoJELPy0WV4bWVw6lcP/3X0H2nnir9Q8xRFJqFUelcL
a63UiF3SS1DLD6X6sIKHJQXO1NrXH6dgE/v6t2TcS/aqyTXKD5qAmyXNqqzehjPt
RemkQkhDzc2TVOAA9aM+Po46ePLp/yELGeCkZ5NHAkmRCyT+rOxC75aoWkjaVjwv
51n+iOYf1Cq/yK1eDtw3WqvS0DxeNpRWk5MMRhru5oGam8ZRZ5lpgbhXWpFAHwX1
nIDi8XnCepc+zVMLIfBqAzELK0pz37sITTPHTaoxRLzd3ACHOm5U1NDzjLN7yIz/
f/cMAyUXROq7CfcxFX7tEaUS4YaBEUVbbnhiTV+cxiQTJyO+5aZeD+3SvDj6r6UY
fVwZHRSO3+QtkK6k2a33y/PaMZySLjB9t6T6UKpbOJyoPeswFjUmlR7G8NdzDeTp
kR6Oq8BkMkxIEgsnfH6ce+js5MzqiiD776Tgn/1+1yOzthEIiL67MHgWC7I8XbVF
BYJ/9NiqyR1gE/OmwzygoA1ImkkaagAt2lAD8o6Ai1DTFxVesQLh4mkQmkMKRPur
bNY3/wmoYBXx5rn8wPRyMvEsNvNN4fqxVCEr2AgumgPyvuzoXl20MpK8Ns9iq2Us
ztJ7YykHdnjgNG9SiM6xOIvYAqTs6NRSUlP8H4X4pBJUMrH4WZ4+JANSavIipn/b
zdfC8pknAU2b4y6wQqk4
=64U6
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Namecoin resolution for Tor Prop279

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Tor devs,

I've written up some documentation on using Namecoin with Prop279.
This can be used for human-meaningful onion service names, as well as
standard Namecoin A//CNAME records.

In theory, this can also be used with arbitrary non-Namecoin naming
systems that speak the DNS protocol, although I haven't attempted to
do so.

Documentation is here: https://www.namecoin.org/docs/tor-resolution/

You can test it with this URL: http://federalistpapers.bit/

Curious what you all think of it -- please feel free to give feedback.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJZ/5k5AAoJELPy0WV4bWVwlSEQAIeF5fiZUBsaiCGyxaDAz97b
l4KVyEKAcPOKCvjryKMqGjxHJPfw9uJJY4x0hD4taXYHszfAMBayOs8EkWHd/eFq
3FDAGW2VaS29k9+y+URiIa9gI3H2et+HgwTOxwCk1O/B2l/2TmWWdGnyh8UCr1a1
yibzBRcamaaMyWwDg7gK0ZvN0WPGwCXiFxVC3fT37dKW2Ve9PwvqZEfsZ/i7eVN1
1Vb+o1Q11qe70yx7XQv3KUFpccU1UsIlR/C0hp0ISxAjV5CpMnN8Lu3/E8s0ViFL
Z3PKL/cpbRltaPPdv8U0mMLy3KY+/u4yRtl2lmHejsNnCwA9gBrZ3XY9A81ZX/wD
QKVBvHf7tO1FlbwKnz0Vb4aY2Ls09vRlXKAQ3zEWtXAT9pofH/dadfI3LYKykeAd
+vuDjDOfsGrIVarn0vWqoVwf43P9iDuaDmk0hNDkbBieEcjIOYbuy3xXiMFxMjpF
Na0StOMYsI1xSlyUqq6+MT5MRrGmh7zk5d8/PYAEdQM8mPJ6wOzgN98sEoGfZLE+
s1rbeZdMiJqne18G9ulUCh4DPOTyZ4K36oJoUAtr/JSt5IO9vGIrTElbw3BjYm6T
7bTeawoWoX+Lx+BJW+dDq57J2r91wwFZdHAqlbQhWvUi8IynVOVqsZUJbw+g9ioP
BAzC5zPauEzD2/awtx/5
=0kqw
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Messenger

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Milan Damjanovic:
> Hello,
> I would like to ask is there any online documentation about how is possible
> to transmit text messages via tor nodes?
> I would like to [try to] rewrite the TorChat Messenger which is written in
> Python 2.7 and wxPython to Python 3x and Qt.
> I cant find any documents  how to transmit messages between two tor nodes
> so anything would be helpful...

Just FYI, TorChat and Tor Messenger are 2 different things.  TorChat is
a long-ago-abandoned project that's somewhat similar in design to the
still-developed project Ricochet; Tor Messenger is an Instantbird fork
(similar to how Tor Browser is a Firefox fork).

(I don't have any answer to your actual question, which I guess is about
TorChat, hopefully someone else will chime in on that.)

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAlreQHQACgkQs/LRZXht
ZXB8ohAAq+8MOwzINol+1DjENiySQX6Z7wo0wO6XHpZR1w6NQ6yANB1rHqtHQN51
i6NDIrEvlyP2hmCQtHdfEOvrKGJonqN1Ce7cuFUh9ri4qT14wRF3JOCxZCT63jt2
JGvBoUVkSty/Lu0VTilAhGb4MbEM2qHTktmSXWrEj0KguNYUvb3mpjglW/ohwxWr
hDZe40JG04/zIQji84YWhWLH3TfhdzYzPL+wsfgTSPEr+ly2+CCQCLp2S7xbxvzv
Sy+XbRgUnDnyDdRa0Qs1djc7MMHczTPY16Mt9tTXu+HdZRXEVkMrlVVzAJOHO26Z
01w86gm9WhOZ13bwevCyOuvxB5LAl95iq/9zuBeW25yqdbwKvATgBJiXFPjPHntU
/toX0Lp3dii1GvuBmJebcjSctS0tM6eVTTMNRRxoK2CBKaNFeOFoXdnOOuPTCke9
OoN1bWCZOPWhySfQvN96sq3iEIPDCNAebaoNNG62yUf05D1HmPeP/Kf7kEoKP9Ji
S6JgJlNr2Y3Sa8v0YCzVF9GXHB+mxlchN4Db/u25SA7k4fFZFIWrU42aZAJC8hv6
9N4/HOqRz2qBBwU6Pmsf1S+tXN6nex4LUKlJhlHvNN1JDsJgLmae2d5Of59pDpjo
ovTRCxw8hk7TkR4rvUfEKVSi6dnDCATl9sCkpKfj+rFME1LEWko=
=2AG7
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Per-peer stream isolation for Bitcoin clients

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Tor-Dev,

I'm trying to gauge the consensus (or lack thereof) in the Tor
development community on whether it's desirable for Bitcoin clients
(e.g. Bitcoin Core) to use stream isolation such that each peer is
accessed over a different circuit.

Some random thoughts on the matter:

1. Bitcoin Core accesses 8 peers by default, so per-peer stream
isolation would use 8 circuits instead of 1.
2. Per-peer stream isolation prevents a single exit relay from feeding
the user a chain that's not the longest chain, so it's desirable from a
Bitcoin security point of view.
3. Per-peer stream isolation would mean more potential for one of the
circuits being deanonymizable, via traffic analysis etc.  It's not clear
to me whether this amount of increased circuits is harmful, or how it
compares to other common usage of Tor such as Tor Browser (which uses
first-party stream isolation, so a user with a lot of tabs open may very
well have 8 or more circuits in use at once).
4. Per-peer stream isolation puts more load on the Tor network.  It's
not clear to me whether this increased load (8 circuits instead of 1) is
so much that it's harmful.
5. Bitcoin Core does do per-peer stream isolation by default.  The
relevant PR is https://github.com/bitcoin/bitcoin/pull/5911
6. Whonix's tor-service-defaults-torrc chooses to disable automatic
per-peer stream isolation for Bitcoin's SOCKS port, and states "Makes
too many connections to different servers.  Should not hurt if they get
through the same circuit."  No citation was given for either claim.
7. The behavior in Bitcoin Core's PR was ACKed by Isis Lovecruft, and an
unspecified Tor developer whom Greg Maxwell talked to.

So, it sounds like there is apparently some disagreement between the two
Tor devs who ACKed this behavior, and the Whonix devs who decided not to
enable it.

Curious what the general feeling in the community is.

(I understand that Isis no longer is active in Tor, so I'm not CC'ing
them.  I am CC'ing Patrick from Whonix in case he wants to weigh in.)

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl0VKAIACgkQs/LRZXht
ZXD3rRAAydyiDv2NVU8rPopr+FkTVclNAA3gM3BKjhZH1EGqya54Xr0OdsTR3VUQ
gBMz5HiexbFnE7VTysnB6ePP/PpLRlAlTj1zLXFCT90H+s1kj84WpjxNZJaguLIJ
zGOQKhqgId9f1pjv7or8DYDrdzT0bfOzKREFM+Yx5TTgPfvxXC9Ug6U1sx5sp7AA
jCAZnrjqWSK+IrNnwrayL2vSPByt+djsK2YPLnq13frKMdonMw+IITVOvT9w5LZt
I/MQa2UujG5DU0owI0t5XmJ7ZQxehcHdAuqU/BfZ5OQVjCH3QgVNwRjlGPaaag+f
y9wMVG0X4cbuvg5x8sar/n8UCR1sDJmlSuN7C6AwE2/e0RU0g67wfTgNcqFlIHta
9t8ORsFUxN6rDtRkbq0FE7xgSYbT9cDtjDFJMhG8oOc0Ibc9EhIJkGETz1amHNUo
GFEBAEircjPJ+KZBsHsQGrLUwpiM6zPbPfkVWwA7dTn4peESSed0Yjwawcn2wpiE
X2TMzhhXpzTjtqpBcroSDKRMum5z/VksEZ3d2MyfIj/caYVXXxPZYS1DqOGtKxYc
uiDCRpL4b/ouJ1FbT1sxHpwTp5e+62XFnfXsoz3Wa9jkrA75kgnnb2kfcjNW/Fq/
6HgLhasriz4jg2iya9rScuUnmU1Ewa8st0bNDGK83qYHofCdvCg=
=1u2L
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Per-peer stream isolation for Bitcoin clients

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks everyone for the excellent feedback, that was very helpful in
understanding the issues at play.

s7r:
> But this is not the proper way to use Bitcoin behind Tor. So stream
> isolation for clearnet type circuits shouldn't even be a concern.
> Whonix's tor-service-defaults-torrc chooses to disable automatic
> per-peer stream isolation for Bitcoin's SOCKS port and I think it does
> the right thing, because this is not how Bitcoin should be used behind
> Tor.

Yes, I'm aware that Bitcoin Core supports stream isolation without
relying on a torrc setting.  Even if Whonix is doing the right thing
here, the comments in Whonix's file suggest that they're doing it for
the wrong reason.

It should also be noted that not all Bitcoin clients do what Bitcoin
Core does (and in fact part of the motivation for my inquiry was to
determine if I should be submitting patches to those clients to make
them mimic what Bitcoin Core does).  Using a torrc setting would
probably provide some useful defense-in-depth in case a Bitcoin client
isn't doing stream isolation on its own.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl0bYTcACgkQs/LRZXht
ZXCSeg//Q9HztuCzK8iVNeu193xr711MquKabRUH/d08NRHTFW7Ltuwns31jGPel
JPcX0e01u/2yT7Rzzc2Ryx5JcGHv6kOjOmY2OD3QHnVUHVhZBEyvQtlvYw2SKKli
8nEUmZotLOxv2X3/tc7RgNCHn0982F1BcJRuZHd8KpswV0tcG801HzkZz+W5NJ/4
WQO6VNnYOlv4ARddjVuxWhkqkHACmnQJ/z7nKqO7O2b54gWy7FEPhfWjHsbHPlo8
MaXwQdunOYtkYJ/afQA4bLb7Rmg50xjRzoO1oWK68yKqqX2hOe1dV+WfGak63eR/
eY3xjM6gLqR8jxdtW491BgatAh0hNr7q/V55VEXoMq1g/QL2JW43LhCfJI0SuT+h
K3LVnX9iuq+MIMEHuJ1eVM7rWVO5g2thpFfvnCR82faCUKZa6VRoS/4r1XGqU0rW
1pg1b67Cu4iVVmKdSmlOHDNhk1yZOY5HU3bpM4BeZi/1dqvZG+yOMtVgYGVPl1ma
iXsfMcbTWIXCEAobAanbgG6NEgiUQUCm39yp+mqQErd4VkRc79kCHII4VznjuoZ7
jLpRT28OA6Xgzvby+AfFEXX/Mot2BwX33aoQX4nKk+aWmg1CG6xtbfjLKgRhNsMx
Goca1Cbc8zqsBZzCjOxgDWFSDrj9Yxg5+cn5AG4kAN2M5aVEw6A=
=pE+P
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Timing of opening pre-emptive circuits?

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Tor-Dev,

I'm curious what the timing is of Tor's opening of preemptive circuits.
 Specifically, consider the following attack:

1. A new stream is assigned to a clean circuit.
2. Because of the above, that clean circuit is now a dirty circuit.
3. Because of the above, the number of clean circuits is now decreased
by 1.
4. Because of the above, the number of clean circuits is now lower than
the number that Tor wants to have open.
5. Because of the above, Tor opens a new preemptive circuit.
6. An attacker who can observe the circuit in (1) and the circuit in (5)
can deduce by temporal proximity that those 2 circuits belong to the
same client.

This attack seemed obvious enough to me that I assumed that Tor must
have some kind of countermeasure to it, e.g. random delays in opening
preemptive circuits.  However, the tor-path specification doesn't
mention any such countermeasure, and based on a brief search through the
Tor source code, all I can find is that Tor opens preemptive circuits
using a function that always gets called once per second (with no
mention of any delay beyond that one-second interval, random or
otherwise).

So, does Tor make any effort to mitigate the above attack?  If so, what
mitigations are present, and where would I find them (in both the spec
and the source code)?  If not, is there any documented reason (e.g. "the
attack is too hard to pull off" or "we want to mitigate it but haven't
gotten to it yet") for the lack of mitigation?

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVB3fdzAraEcoBtkSs/LRZXhtZXAFAl2CoycACgkQs/LRZXht
ZXDyjhAAk3F6fJUvNl4FHws6IIBHWXby/zC7MLzr9zR3sIC3RY4f/I7XBDTKKfMg
iOehJlBEksm5sRz6nlybUBivsJ0WRL8VCT3rEK3+LQM7JrYNvGajolEw2apBUeB3
+Vg+Quo5JzTZrjCtXljxdps/hhC1YwEyN6pxxn2137q4XAsRPQgSCcWpsBuDTffb
LFRwyGrNxk6chbpQc0GIWQRoeElxFwaLbUrZdGtaaEjBXY2oWoan1TUB34MAVNzF
1o6DlaO2JQ7weHVHoXlTlXS7gt84/WyY0xaHUY9ONHwrhgDPGv3N5+Fa2Em+PvGx
ik+4iSCzPf6aKY0iUv1AsWKiaq8rRsMToyNzNZ048uYHk2IK2Zrbqh4Nm44RTzKD
84tJU71calRdNhbwuvmgsYKh26Ad9ALf9BzDeiweA3c5ZP0JP0OlLcAN9c056WT3
FQbChA1edZkWkPvBjGtl4l7ROIx6wkNpWgaQsYUCMveszB2Rm38BQw5sYLh8i6ha
AlT3UVs/GJscSSsfmHGrTisao444Etp4J/+SFe1aNJwfOogbEfgJ1jRf8V5dlYEb
rcicgkwmnBf01vnVaUO9C6/lToUa9i7r3BD3s6OQW24qz2ixieS3K6NxxxqMrVQ1
vFArleJIYA/FsDM2NPbeaUQA9z5GJj5X3FcPUPLLF+y5G/0HE14=
=aBRL
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Timing of opening pre-emptive circuits?

[Jeremy Rand]

s7r:
>> Hi Tor-Dev,
>>
>> I'm curious what the timing is of Tor's opening of preemptive circuits.
>>  Specifically, consider the following attack:
>>
>> 1. A new stream is assigned to a clean circuit.
>> 2. Because of the above, that clean circuit is now a dirty circuit.
>> 3. Because of the above, the number of clean circuits is now decreased
>> by 1.
>> 4. Because of the above, the number of clean circuits is now lower than
>> the number that Tor wants to have open.
>> 5. Because of the above, Tor opens a new preemptive circuit.
>> 6. An attacker who can observe the circuit in (1) and the circuit in (5)
>> can deduce by temporal proximity that those 2 circuits belong to the
>> same client.
>>
>> This attack seemed obvious enough to me that I assumed that Tor must
>> have some kind of countermeasure to it, e.g. random delays in opening
>> preemptive circuits.  However, the tor-path specification doesn't
>> mention any such countermeasure, and based on a brief search through the
>> Tor source code, all I can find is that Tor opens preemptive circuits
>> using a function that always gets called once per second (with no
>> mention of any delay beyond that one-second interval, random or
>> otherwise).
>>
>> So, does Tor make any effort to mitigate the above attack?  If so, what
>> mitigations are present, and where would I find them (in both the spec
>> and the source code)?  If not, is there any documented reason (e.g. "the
>> attack is too hard to pull off" or "we want to mitigate it but haven't
>> gotten to it yet") for the lack of mitigation?
>>
>> Cheers,
> 
> 
> Hi Jeremy,
> 
> When I read your checklist from 1 to 6 I remembered that there was a
> research made on this [1] (I think you are talking about the same thing,
> except not mentioning where your "attacker" is positioned). If a counter
> measure existed it would have been documented in the Tor spec for
> tor-path of course, so I guess that part is correct.
> 
> There is an obvious straight forward solution to fix it [2], except
> AFAIK nobody had time to work on this yet.
> 
> I guess this is because this threat is not very scary, it is nice to fix
> it of course, but correlating anonymous circuits to the same anonymous
> user is much less scary than:
> - guard discovery attack;
> - guard partitioning attacks / path-bias attacks;
> - routers netflow recording of traffic patterns;
> - v3 onion services;
> 
> There has been a lot of work into these directions.
> 
> [1]:
> https://lists.torproject.org/pipermail/tor-dev/2014-September/007517.html
> 
> [2]:
> https://lists.torproject.org/pipermail/tor-dev/2014-September/007518.html

That's great info, thanks for the references!

> If this thread model is interesting to you or your project(s), you can
> take Paul's ideas from [2] and write a patch. It is also going to need a
> proposal before it will be merged into Tor but at least there will be
> some action ;)

At this time it's unlikely that I'll have free time to write a patch,
especially as this is someone outside of my area of expertise.  That
said, this does seem like something that would be beneficial to patch,
so I certainly do hope someone volunteers to do it.  (Maybe me in the
distant future.)

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Exposing onion service errors to Tor Browser

[Jeremy Rand]

George Kadianakis:
> Hello list,
> 
> we've recently been thinking about how to expose onion-service-related
> errors to Tor Browser so that we can give more useful error pages to
> users.  We currently return "Unable to connect" error pages for any kind
> of onion service error, and I think we can do better.
> 
> This is a thread to think about the errors we want to expose, how that
> should look like, and what options we should give to the users when it
> happens. Relevant master tickets are #30022, #30025 and #3.
> 
> We decided (in #14389) that Tor will export these errors through the
> SOCKS port, and the relevant spec is proposal 304 [0].
> 
> As part of #30090 antonela started making a table of potential
> errors. I'm gonna use that in this thread and also add a few more.

Hi George,

In the hypothetical scenario that Namecoin (or any other naming layer)
gets introduced to Tor Browser, it is likely that some error values
specific to the naming layer are going to be useful to convey to the
user.  My preference is to defer that issue until after Namecoin is
introduced to Tor Browser (unless you think it's important to prepare
for in advance?), but I figured it's worth at least getting it onto your
radar.

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Exposing onion service errors to Tor Browser

[Jeremy Rand]

d...@foundingdocuments.org:
> Please forgive me if I misunderstand things, but I thought leaked v3.onion 
> addresses with (properly set up) authorized onion services 
> (authorized_clients/*.auth & corresponding client-side .auth_private) can’t 
> be loaded. Thus providing instant, inexpensive DOS protection, and denying 
> the malevolent (and anyone) the opportunity to even know a specific onion 
> address is in use. And keeping them from trying again later, and again, etc.
> 
> I am definitely in favor of feedback and clear error reporting, but I am not 
> clear about how these authorization-only onion services will be affected. 
> 
> Is tor going to be changed such that unauthorized clients -- clients without 
> a proper .auth_private file -- are going to be able to learn if a specific 
> .onion domain is in use? Will the local tor inform the user that in effect 
> that onion address is in use but perhaps X'F4' or X'F5' ?

AFAIK this proposal has nothing to do with changing the Tor onion
service protocol; it's solely related to conveying errors to the user
that the Tor daemon used by Tor Browser already has access to.  The
security properties of onion services can't be changed by this -- if
they could be, then this would be security by obscurity, which is a scam
that the Tor devs (and any other legitimate software developers) don't
engage in.

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

[Jeremy Rand]

Alexander Færøy:
> I wonder if it would make more sense to have an onion-aware
> DNSSEC-enabled resolver *outside* of the Tor binary and have a way for
> Tor to query an external tool for DNS lookups. Such tool should be
> allowed to use Tor itself for transport of the actual queries. One of
> the best parts of Tor (in my opinion) is the Pluggable Transport
> subsystem. This subsystem allows external developers, researchers, and
> hackers to build new technology that benefits users in censored areas
> *without* having to alter a single line of C code in tor.git.
> 
> Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to
> configure their Tor process to *never* use the built-in DNS subsystem in
> Tor, but instead outsource it to an external process that Tor spawns on
> startup. This process could use .onion's to reach a
> DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up
> via DNS.
> 
> A "Pluggable DNS" subsystem would be much less code, I believe, and it
> wouldn't require us to have a DNS+DNSSEC implementation in the heart of
> Tor to maintain in the future. Such a system would be similar to the
> proposed design for Name => Onion lookups defined in proposal #279 by
> asn, yawning, and dgoulet.

Hi Alex,

FYI I already wrote a Prop279 provider that looks up the names via DNS
(it's aptly named "dns-prop279"); it does pretty much exactly what you
describe.  It doesn't handle DNSSEC validation itself (it assumes that
you've specified a DNS server that you trust -- most likely one running
on localhost).  Stream isolation can be handled via an EDNS0 field (and
I'm guessing it would not be difficult to patch an existing DNS server
to respect that EDNS0 field).  I wouldn't be surprised if it's easy to
make dns-prop279 do DNSSEC validation itself (and not use a
localhost-based DNS server) if that's desired -- the library it uses
(miekg/dns) does claim to support DNSSEC validation, though I've never
tried testing that feature.

I originally wrote dns-prop279 for Namecoin purposes, but I see no
reason it couldn't be used to achieve DNSSEC support in Tor.  If there's
interest in pursuing this, let me know, I'm happy to contribute.

Code is at https://github.com/namecoin/dns-prop279

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

[Jeremy Rand]

Alexander Færøy:
> Hey Jeremy,
> 
> On 2020/05/15 15:53, Jeremy Rand wrote:
>> FYI I already wrote a Prop279 provider that looks up the names via DNS
>> (it's aptly named "dns-prop279"); it does pretty much exactly what you
>> describe.  It doesn't handle DNSSEC validation itself (it assumes that
>> you've specified a DNS server that you trust -- most likely one running
>> on localhost).  Stream isolation can be handled via an EDNS0 field (and
>> I'm guessing it would not be difficult to patch an existing DNS server
>> to respect that EDNS0 field).  I wouldn't be surprised if it's easy to
>> make dns-prop279 do DNSSEC validation itself (and not use a
>> localhost-based DNS server) if that's desired -- the library it uses
>> (miekg/dns) does claim to support DNSSEC validation, though I've never
>> tried testing that feature.
> 
> Very interesting.
> 
> I think proposal #279 only tries to solve the subset of name look ups,
> which is about looking up onions from a human name. The work in this
> thread is to replace all name lookups *except* for Onions. It could very
> well be that it would be easier to extend proposal #279 by having it
> handle all lookups and not just for .onion's, but I think my intuition
> says that it should be two different systems as onion lookups is still a
> much more open question whereas Tor will need to support ordinary DNS
> for many years into the future.
> 
> If `OnionNamePlugin` allowed you to specify `.*` for "everything" as the
> TLD specifier, then it might be possible to implement such system using
> proposal #279 :-)

Hi Alex,

The Prop279 spec text is ambiguous about whether the target is required
to be a .onion domain, but the implementations (TorNS and StemNS) do not
have that restriction.  TorNS and StemNS allow a Prop279 plugin to
advertise acceptance of any domain suffix (haven't explicitly tried the
root zone as an suffix, but if that doesn't work, it's a bug that should
be easy to fix) and can resolve them to any result (e.g. an IP address,
a .onion domain, or another DNS name a la CNAME).

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

[Jeremy Rand]

Alexander Færøy:
> Hey,
> 
> On 2020/05/15 16:36, Jeremy Rand wrote:
>> The Prop279 spec text is ambiguous about whether the target is required
>> to be a .onion domain, but the implementations (TorNS and StemNS) do not
>> have that restriction.  TorNS and StemNS allow a Prop279 plugin to
>> advertise acceptance of any domain suffix (haven't explicitly tried the
>> root zone as an suffix, but if that doesn't work, it's a bug that should
>> be easy to fix) and can resolve them to any result (e.g. an IP address,
>> a .onion domain, or another DNS name a la CNAME).
> 
> In proposal #279 the subprocess passes the `RESOLVED` message to Tor
> once it is has completed a name look up. The `RESOLVED` message is
> defined as follows:
> 
> ``When the name plugin completes the name resolution, it prints the
> following line in its stdout:
> 
> RESOLVED   
> 
> where QUERY_ID is the corresponding query ID and STATUS_CODE is an integer
> status code. RESULT is the resolution result (an onion address) or an 
> error
> message if the resolution was not succesful.''
> 
> Here the `` must be an onion address. We would have to change
> that, such that an IP address can be returned as well :-)

Hi Alex,

The ambiguity I was referring to is that while the section you quote
does require that the result be a .onion domain, below it is this note:

> Tor MUST validate that the resolution result is a valid .onion name.
> XXX should we also accept IPs and regular domain results???

Prop279 is clearly labeled as a draft, so this makes it appear that no
decision was reached on whether the result should be required to be a
.onion domain.

My opinion is that accepting non-.onion addresses as results is
desirable (both because it's useful for the Namecoin use case and
because it's useful for the DNSSEC use case that we're discussing).

Cheers,
-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmob...@airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jer...@veclabs.net is having technical issues at the
moment.



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev