Re: [tor-dev] The Onion Name System (OnioNS)
Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. Why do you limit names to 128 characters, when DNS supports 253? With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'. All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS). So maybe Tor can plan to incorporate .tor, .bit (namecoin), .onion and .gnu. After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with .gnu and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well. On 05/19/2015 01:48 AM, OnioNS Dev wrote: Hello everyone, I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation. Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name. I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor - onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. Clients don't need a copy of the Pagechain to use the DNS, but
Re: [tor-dev] Namecoin .onion to .bit linking
-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
[tor-dev] Namecoin .onion to .bit linking
-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
On Tue, May 19, 2015 at 09:43:30 -0500, Jeremy Rand wrote: 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. 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. -- Daniel Martí - mv...@mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C pgps8KbRXSLPG.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-requ...@lists.torproject.org wrote: Subject: Re: [tor-dev] The Onion Name System (OnioNS) From: Christian Grothoff groth...@gnunet.org Date: 05/19/2015 03:24 AM To: tor-dev@lists.torproject.org Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. I will put that on the to-do list. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). Thanks, I'll make those corrections. Good to hear from someone who is part of that system. I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. My scheme is better than Namecoin in several key ways: 1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network. 2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor. The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot. It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data. Why do you limit names to 128 characters, when DNS supports 253? For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain. With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and
Re: [tor-dev] The Onion Name System (OnioNS)
In the sense that the IPv6 addresses provided by Onioncat are namelike, these may be of reference interest (I do not know if Bernhard has produced paper/slides/video for the new HS crypto model in english yet. I hope to look it over.) https://www.youtube.com/watch?v=Zj4hSx6cW80 https://www.youtube.com/watch?v=SBb2jy80Itc ___ 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
-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 Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services. 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). 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. 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. 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, each with their own approach. Let's see if we can work together here, we might be able to help one another. Jesse V. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW52lAAoJEK2XNk/CC+yAUtQH/1a9zZQK2XYsQofGt+qtrAA0 MZmBHMTC+lBLcpq1ZSIYCD+vJ8DEO1Aoqrzfj7RVsS5T1dfXZ5B4D+u2XB+Obg1+ uW86/cWQ3S2UgFRg5Mg0+6C+3T7sIwBya3foXg0/dETh4R9J2QzSG7iobsvjuivr TEUh7iGl+9zBDHad3s5ZZRBms9ZHk4fQy1ckFx6h9bvh5ybzaZZKc8bAYdRF1yTi RQw4MmtoJ4e2MZf7Ze9qVn863KOLQQzOlw0ddQ4tCLpHfBwr+l+lK5waGflVYLjU C2RVt9QUS83PgDXY3sKp+kIlfqp0Oupf7ZFqq6xAHWIHORvcr8vERtFadWLiQVw= =vl1G -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
-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, each with their own approach. Let's see if we can work
[tor-dev] [Patch] or/config.c for MSVC
This gcc-centric macro in or/config.c doesn't work well in MSVC v16/18: #define COMPLAIN(args...) \ STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END I suggest it should be patched like this: --- a/config.c 2015-05-06 22:22:09 + +++ b/config.c 2015-05-06 23:15:57 + @@ -2571,8 +2571,8 @@ #define REJECT(arg) \ STMT_BEGIN *msg = tor_strdup(arg); return -1; STMT_END -#define COMPLAIN(args...) \ - STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END +#define COMPLAIN(args, ...) \ + STMT_BEGIN log_warn(LD_CONFIG, args, ## __VA_ARGS__); STMT_END /** Log a warning message iff bfilepath/b is not absolute. * Warning message must contain option name boption/b and --- All recent compilers supports '__VA_ARGS__'? -- --gv ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
