Re: [tor-dev] onion v2 deprecation plan?
On Wed, Apr 25, 2018 at 04:58:36PM -0400, grarpamp wrote: > In onionland, there seems to be little knowledge of v3, thus little worry > about v2 in cases where v3 would actually apply to benefit, that's bad. v3 onion services just seem like a way worse deal to the average user and the unknowledgeable admin. Mainly because the addresses are way too long. I can remember a couple of v2 addresses, but not a single v3 address. So that's just bad advertising from the start. Before at least Facebook, DuckDuckGo, The New York Times, the Debian Project and even the Tor Project themselves (!) have rolled out their v3 onion services, one shouldn't even think about deprecating HSv2. It's going to be around for many years to come, taking for them just as long to vanish as an SSL version, I think, unfortunately. -- OpenPGP Key: 47BC7DE83D462E8BED18AA861224DBD299A4F5F3 https://www.parckwart.de/pgp_key signature.asc 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] onion v2 deprecation plan?
It's not just about getting the protocol stack right, but also the
ancillary software environment; people keep asking me for "V3 support in
EOTK" and my stock response is this:
BEGIN
OnionBalance requires STEM support for V3, before it can be updated
(possibly a substantial rewrite will be needed) to support the new format
onions. It's not only a matter of "longer addresses" but also a matter of
cross-signing the descriptors to support new-style cryptography, so in fact
it might be safest to create a new, separate OnionBalance for V3.
So: STEM needs updating and testing for V3, and then OnionBalance needs to
support the new STEM library and encryption. Then (for me) EOTK needs to
support the new OnionBalance.
I am not expecting a solution to ship until 2019, earliest.
END
...and that's even without refactoring the other bits of EOTK to address
the changes when STEMv3 lands.
OTOH, I have been performance testing simultaneous regular-expression
matching of v2/3 addresses, and so far this is the winner:
"\\b([a-z2-7]{16}(?:[a-z2-7]{40})?\\.onion)\\b"
...and it's already in the codebase at
https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt#L299
- alec :-)
--
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
Jonathan Marquardt writes: > On Wed, Apr 25, 2018 at 04:58:36PM -0400, grarpamp wrote: >> In onionland, there seems to be little knowledge of v3, thus little worry >> about v2 in cases where v3 would actually apply to benefit, that's bad. > > v3 onion services just seem like a way worse deal to the average user and > the unknowledgeable admin. Mainly because the addresses are way too long. I > can remember a couple of v2 addresses, but not a single v3 address. So that's > just bad advertising from the start. > IMO if you have the ability to memorize v2 addresses by heart, you are already not an average user. Average users just google most things they try to visit. That said, I do share your concerns, and that's why I mentioned that finding a solution to the onion name issue is a priority before v3 can go mainstream (or even v2). > Before at least Facebook, DuckDuckGo, The New York Times, the Debian Project > and even the Tor Project themselves (!) have rolled out their v3 onion > services, one shouldn't even think about deprecating HSv2. It's going to be > around for many years to come, taking for them just as long to vanish as an > SSL version, I think, unfortunately. Agreed. We are indeed a long way from deprecating HSv2 :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
> OnionBalance requires STEM support for V3 Hi Alec, would you mind clarifying what you need from Stem? As far as I'm aware Stem supports v3 onion service creation... https://trac.torproject.org/projects/tor/ticket/25124 See the 'version 3' note at the end of... https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service I'm unaware of the ball being in my court on any v3 Onion Service stuff. If there's something I should have on my radar then please let me know! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
On Fri, Apr 27, 2018 at 8:01 AM, Alec Muffett wrote:
> OnionBalance
Forgot to include this in the former list of
common / useful onion tools, thanks.
If anyone knows of others, feel free to add to thread.
> OTOH, I have been performance testing simultaneous regular-expression
> matching of v2/3 addresses, and so far this is the winner:
>
> "\\b([a-z2-7]{16}(?:[a-z2-7]{40})?\\.onion)\\b"
Did you post the results of the various RE engines and RE's somewhere?
Some of the onion services out there might find it useful in their backend work.
> ...and it's already in the codebase at
> https://github.com/alecmuffett/eotk/blob/master/templates.d/nginx.conf.txt#L299
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
On 27 April 2018 at 19:48, Damian Johnson wrote: > > OnionBalance requires STEM support for V3 > > Hi Alec, would you mind clarifying what you need from Stem? As far as > I'm aware Stem supports v3 onion service creation... > ... > I'm unaware of the ball being in my court on any v3 Onion Service > stuff. If there's something I should have on my radar then please let > me know! Hi Damian! That's awesome, and good to know - I first wrote that text a few months ago (on the basis of David's comments in that ticket) and haven't revised it since, so I am heartened to see progress. However I am also not the best person to say what else will be needed, because that would probably be Donncha re: the future of OnionBalance for v3. At the moment in OnionBalance the v2 Introduction Points of the (predetermined) worker onions are passively scraped from the HSDir; the descriptors are parsed, the IPs are blended and re-combined and re-signed under the master onion key (eg: nytimes3xbfgragh) and then published back to the HSDirs, with the result that NewYorkTimes-browsing clients end up communicating with 1 of N possible "worker" daemons, thereby sharing the load. My understanding - and please jump in, if I am wrong - is that the synthesis of a v3 descriptor which blends the introduction points of several independent v3 "worker" Tor daemons will be a more complex affair than the existing process, because (?) the "worker" tor daemons will somehow have to be more actively involved - apparently they may have to sign the v3 Introduction Points themselves, though I am not sure how that will work for a blended descriptor? Multiple/distinct signatures, perhaps? The last opportunity I had to speak with anyone (re: this) was more than 1 year ago, so I am rusty, and I apologise if I have gotten some details wrong. So: OnionBalance relies heavily upon Stem ( https://github.com/DonnchaC/onionbalance/tree/develop/onionbalance) and I am not qualified to say what, if any, additional v3 Stem features will be useful or outstanding to support the descriptor-blending that is needed for loadbalanced configurations. But OnionBalance for v3 will certainly be necessary. :-) -a -- http://dropsafe.crypticide.com/aboutalecm ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
> Yes indeed. The sooner we deprecate v2 the sooner we can stop worrying > about malicious HSDirs. yes, that was indeed the motivation for my email (mostly because I see how much time goes into the constant detection and rejection of these relays - not by me) > And also we will be able to reduce the > requirements for becoming an HSDir which will strengthen and make our > network more robust. > > That said, I think we are unfortunately still far from deprecating v2 > onions: thanks for listing all these relevant ticket IDs, I pasted your email into trac and I made them child tickets of https://trac.torproject.org/projects/tor/ticket/25955 lets try to link all relevant tickets there -- https://mastodon.social/@nusenu twitter: @nusenu_ 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] onion v2 deprecation plan?
On Fri, Apr 27, 2018 at 6:44 AM, Jonathan Marquardt wrote: > v3 onion services just seem like a way worse deal to the average user and > the unknowledgeable admin. Mainly because the addresses are way too long. Then it's analyzing whether shifting the default to v3 for the clueless and the perhaps at risk is helpful anti-footshooting more than say string length. What are the tools and threat models where v3 overrides v2. Do they include proper educational docs and config options. Are such things themselves an intolerable risk. > Before at least Facebook, DuckDuckGo, The New York Times, the Debian Project What capabilities, including string representations, do such large public realworld services, and their users, need. Are those served by v3 and or v2. Are they trading something for the other. > Mainly because the addresses are way too long. Though ux was mentioned, v3 can be mangageable by users to whatever degree. In onionland, there's usually commentary that some do memorize a few memorable v2 onions if generated lucky (phonetic, etc) or by regex matching generators, fewer users brute memorize hard v2 strings, the rest just bookmark / file them, or use various search / entry portals. Though v3 is a bit unwieldy, that gets traded off by those that need the capabilities that only v3 can provide. Among those that do know of v3, but don't explicitly need its capabilities, yes, they often choose v2 for that reason, in that case that's probably reasonable. "Deprecation" may be vague term... a) If defined as shifting v3 to be "provisioned by default" via docs and function, while *continuing to support v2* functionality on the network, there's no problem, everyone is happy. b) While v2 and v3 do share some capabilities, since v2 and v3 do offer their own exclusive subset of capabilities to users that cannot currently be found in the opposing version, *removing v2 support* is a definite issue. v3 is a nice advancement and is needed by lots of users for what it can do for them, just as v2 is. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] HS v3 client authorization types
As I am currently implementing the client authorization for onion service v3 (https://github.com/torproject/tor/pull/36), I found some problems in how we should let the users configure the client auth for their services. Before getting into the problem, I will explain how it works first. -- Each client will have two private keys to authenticate with the service. One is x25519 key and the other is ed25519 key. The x25519 one is used to decrypt the descriptor when the client wants to access the service, so if the client is not authorized, it will never know the introduction points, the intro auth keys, and so on, and then it absolutely cannot access the service. The ed25519 one is for another layer of authentication. Even if the client can decrypt the descriptor using the x25519 private key, it still need to have the ed25519 to authenticate itself directly to the service using the extension field in INTRODUCE1 cell. At first glance, it seems that the ed25519 one is not necessary because, if the client is able to decrypt the descriptor, it already means the client is already authenticated. Why do we need to have another layer of authenticate? The answer is that the ed25519 provides more find-grained access control for example: 1) you could use it to revoke a client without the need to rotate all the intro points and push new descriptor. 2) you can have more fine-grained control on your users and potentially offer different types of access structure to different users using their ed25519 keys as identifier. -- The spec says that the client must have both keys and use both to authenticate, but, for me, these two things are quite independent. I think they can be considered two different authentication types. The service should be able to enable one and disable the other. For example, If I disable the x25519 while I enable ed25519, I can add a new client immediately without the need to rotate the intro points. If rotating intro points is not an issue and the only purpose of ed25519 is to have more fine-grained access control, the current spec is fine. But if rotating intro points is an issue, we should rethink about this. So, I created a PR for the change in torspec. https://github.com/torproject/torspec/pull/7 (in the PR, the x25519 auth is called 'basic' and the ed25519 auth is called 'intro') We need your opinions about this. Should we let the service enable one while disable the other? Or should we require the service to enable both for all clients? If you want to let the service be able to enable one while disable the other, do you have any opinion on how to configure the torrc? Cheers, haxxpop This is a discussion log that we had earlier. [22:39:23] v3 "basic" auth is different from v2 "basic" auth, right? Perhaps a different name-string for the v3 one would be good? [22:39:44] meejah: good point [22:39:57] perhaps we can name it "pubkey" auth or something more UX-y [22:40:35] asn: sounds good to me (my perspective is to avoid naming-weirdness for controllers and having to explain to users "well, this 'basic' is different from this other 'basic' because you said version=3") [22:40:43] right [22:40:44] makse sense [22:40:51] haxxpop: ^ what do u think [22:40:51] ? [22:45:01] meejah, asn yes I agreed. maybe we should change it to something else [22:46:10] meejah, asn In fact, the word 'basic' appears only once in the v3 spec ! [22:48:05] haxxpop: yeah... perhaps we can rename it to "pubkey" which describes it pretty well for nerds. or to "standard" which is a synonym for "basic" and it will confuse everyone. [22:50:59] asn, I think both "basic" and "intro" use pubkeys. [22:51:26] asn, I think if we call "basic" "pubkey", it may imply that "intro" doesn't use pubkeys. [22:51:35] true [22:52:20] i'm still not sure if i like: [22:52:20] +HiddenServiceAuthorizeClient basic client-name,client-name,... [22:52:20] +HiddenServiceAuthorizeClient intro client-name,client-name,... [22:52:30] mainly because it's gonna be quite hard to explain to people what these two lines mean [22:52:34] (to hs operators) [22:52:37] like what's the difference [22:52:42] and usually they should have both enabled [22:52:53] what i imagined initially is that we would keep the torrc logic the same [22:53:04] and maybe expose a torrc option for advanced users to do HiddenServiceDisableIntroAuth [22:53:07] or something [22:53:11] anyway i need to think about this! [22:53:25] asn, Nice point [23:08:35] asn: haxxpop: "pubkey" sounds good to me. People who are "just clients" probably don't care what the string is (? maybe? UX people?) and people running the services probably count as "nerds" :) [23:08:59] agreed [23:09:02] (but, I don't personally understand what these schemes are so maybe I shouldn't be naming them ;) [23:09:08] ideally those things should not be exposed to the users anyway [23:09:19] they should be wrapped by the browser or something [23:11:46] asn: in tx
Re: [tor-dev] HS v3 client authorization types
Suphanat Chunhapanya writes: After reading the spec diff and your mail, I'm still not sure I understand the distinction -- if the x25519 is used to decrypt the descriptor then: > The spec says that the client must have both keys and use both to > authenticate, but, for me, these two things are quite independent. I > think they can be considered two different authentication types. The > service should be able to enable one and disable the other. For example, > If I disable the x25519 while I enable ed25519, I can add a new client > immediately without the need to rotate the intro points. ...how does this work? If the client doesn't have the x25519 key how can it access the descriptor? Also, separately addressing the issue of configuration and terminology, I think it's probably best if "users" (service operators and clients) don't actually have to touch the keys. This sounds fraught with peril: a service operator has to copy-pasta the right half of the correct two keys, securely deliver them to a client and the client has to put them in the right place in a config-file. Then, if the service client has a problem later they have to remember NOT copy-paste the whole config when asking for help... sounds like lots to go wrong :) and I don't think this can be solved by tinkering with the names/layout of torrc options, personally... -- meejah ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
On Fri, Apr 27, 2018 at 04:03:00PM -0400, grarpamp wrote: > a) If defined as shifting v3 to be "provisioned by default" via docs > and function, while *continuing to support v2* functionality > on the network, there's no problem, everyone is happy. > b) While v2 and v3 do share some capabilities, since v2 and v3 > do offer their own exclusive subset of capabilities to users > that cannot currently be found in the opposing version, > *removing v2 support* is a definite issue. I think that, before making v3 the default, all features from v2 like HidServAuth should be implemented and should have been around for a couple of Tor versions. Also, what would happen to an old Tor instance with v2 onion services configured after the upgrade? These onion services should definitely not automatically be switched to v3, as it could break many configurations on systems with automatic software updates. I suggest that, if Tor sees an onion service configured in torrc and if there's no "HiddenServiceVersion 3" in torrc and there are v2 keys in the HiddenServiceDir, it should continue to serve a v2 service. But leaving a note in the log about v3 services if there's a v2 configured could be a good thing, I think. > v3 is a nice advancement and is needed by lots of users > for what it can do for them, just as v2 is. Totally agreed. -- OpenPGP Key: 47BC7DE83D462E8BED18AA861224DBD299A4F5F3 https://www.parckwart.de/pgp_key signature.asc 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] connectivity failure for top 100 relays
Greetings, ( Meejah and I made txtorcon report the reason for circuit build failures here: https://github.com/meejah/txtorcon/pull/299 My scanner now uses this txtorcon feature: https://github.com/david415/tor_partition_scanner ) I used a collector consensus file: 2018-04-27-19-00-00-consensus wget https://collector.torproject.org/recent/relay-descriptors/consensuses/2018-04-27-19-00-00-consensus and extracted the top 100 relays with the highest consensus weights with stable AND fast flags. ./helpers/query_fingerprints_from_consensus_file.py 2018-04-27-19-00-00-consensus > top100.relays and then performed the scan, building 9900 2-hop tor circuits: detect_partitions.py --tor-control unix:/var/run/tor/control --log-dir ./ --status-log ./status_log \ --relay-list top100.relays --secret secretTorEmpireOfRelays --partitions 1 --this-partition 0 \ --build-duration .25 --circuit-timeout 60 --log-chunk-size 1000 --max-concurrency 100 This resulted in only 307 circuit build failures: echo "select reason from scan_log where status = 'failure' > ;" | sqlite3 scan1.db | wc -l 307 And out of these failures, 301 of them the circuit build failure REASON was reported by little-t tor as TIMEOUT: echo "select reason from scan_log where status = 'failure';" | sqlite3 scan1.db | grep -i timeout | wc -l 301 Here's the non-timeout REASONs for these circuit build failures: echo "select reason from scan_log where status = 'failure';" | sqlite3 scan1.db | grep -vi timeout DESTROYED, FINISHED DESTROYED, FINISHED DESTROYED, CHANNEL_CLOSED DESTROYED, CHANNEL_CLOSED DESTROYED, CHANNEL_CLOSED DESTROYED, CHANNEL_CLOSED I'm curious to try this scan at different times of day to see if results vary. Cheers, David On Tue, Mar 13, 2018 at 11:48:30PM +, dawuud wrote: > > I did another scan, this time with 3 seconds between each circuit > build and set the max connections to 50 with similar results as > yesterday: > > 9354 failure > 2 timeout > 544 success > > most of the circuit build failures happened in under a second: > > echo "select (end_time - start_time) / 1000 as duration from scan_log where > duration < 1 AND status = 'failure';" | sqlite3 scan1.db | wc -l > 9344 > > > txtorcon does expose both the 'reason' and the 'remote_reason' flags > > returned by the failure messages. In fact, it returns all flags that Tor > > sent during stream or circuit failures. > > > > The **kwargs in stream_closed, circuit_closed or circuit_failed > > notifications should all include "REASON" and many times will also > > include "REMOTE_REASON" (e.g. if the "other" relay closed the > > connection). For convenience, txtorcon also includes lower-cased > > versions of all the flags. > > ah ok! I will take a look at this. I'd like to do another scan > while collecting this additional information. > > > Would it be better, then, to pick one first hop and scan (sequentially) > > every second-hop using that first hop? (And maybe have say 5 or 10 such > > things going on at once?) > > Maybe it's ok to make 7,000+ tor circuits sequentially from the same relay > if it's done very slowly? > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc 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] Proposal #291 Properties (was IRC meeting)
teor:
>
>
> > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> >
> > 1. Hidden service use can't push you over to an unused guard (at all).
> > 2. Hidden service use can't influence your choice of guard (at all).
> > 3. Exits and websites can't push you over to an unused guard (at all)
> > 4. DoS/Guard node downtime signals are rare (absent)
> > 5. Nodes are not reused for Guard and Exit positions ("any" positions)
> > 6. Information about the guard(s) does not leak to the website/RP (at all).
> > 7. Relays in the same family can't be forced to correlate Exit traffic.
>
> I think this list is missing some important user-visible properties, or it's
> not clear which property above corresponds to these properties:
>
> * Is Tor reliable and responsive when guards go down, or when I move
> networks, or when I have lost and regained service?
I think this is implicitly provided by #4. Downtime is a security issue.
If (any of) a client Guard(s) are down, and the adversary can detect
this based on client behavior, well, that is a side channel signal that
provides information about the Guard. So by satisfying #4, we also
satisfy the weaker conditions of general reliability and responsiveness.
> I also think it's missing an implicit property, which we should make explicit:
>
> * Can Tor users be fingerprinted by their set of guards or directory guards?
>
> Perhaps this property is out of scope.
I think it is worth considering. We should add it if we need to do
another round of evaluation.
But remmeber that we are already in the situation where Tor is using two
guards for a lot (or all) users right now: it uses a second guard right
now whenever an RP or Exit is the same as the Guard node, or is chosen
from the same /16 or family as the Guard node. Depending on how unlucky
you are, you could be using 2 guards pretty often right now. Just not
often enough to benefit from any multiplexing and netflow padding.
Tor also currently uses 3 directory guards, and unless we set "num entry
guards to use" and "num entry guards" to the same number, these are
different nodes than the primary guard. Miraculously, if we set this to
two, then Tor uses those two primary guards *as* its directory guards.
This means that any proposal that said "Set these to 2" has *less*
fingerprinting than those that did not. My proposal was the only one
that explicitly said this, but I think asn wants this too.
That means if we accept the proposal at the end of my mail, which gets
us strong #1-4, non-strong #5, strong #6 (with mods), and #7, then we'll
have less guard fingerprintability than today.
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HS v3 client authorization types
Hi, > On 28 Apr 2018, at 06:59, meejah wrote: > > After reading the spec diff and your mail, I'm still not sure I > understand the distinction -- if the x25519 is used to decrypt the > descriptor then: > >> The spec says that the client must have both keys and use both to >> authenticate, but, for me, these two things are quite independent. I >> think they can be considered two different authentication types. The >> service should be able to enable one and disable the other. For example, >> If I disable the x25519 while I enable ed25519, I can add a new client >> immediately without the need to rotate the intro points. > > ...how does this work? If the client doesn't have the x25519 key how can > it access the descriptor? If the service does not encrypt the descriptor with an x25519 key, then the client does not need a key to read it. > The spec says that the client must have both keys and use both to > authenticate, but, for me, these two things are quite independent. I > think they can be considered two different authentication types. The > service should be able to enable one and disable the other. For example, > If I disable the x25519 while I enable ed25519, I can add a new client > immediately without the need to rotate the intro points. > > If rotating intro points is not an issue and the only purpose of ed25519 > is to have more fine-grained access control, the current spec is fine. > But if rotating intro points is an issue, we should rethink about this. > > So, I created a PR for the change in torspec. > https://github.com/torproject/torspec/pull/7 > (in the PR, the x25519 auth is called 'basic' and the ed25519 auth is > called 'intro') Please use different words from v2 to avoid confusion. Please use words that describe what a thing *is*, not how secure it is, or what it should be used for, or what level of the design it is on. (We made that mistake when naming "hidden services".) I would recommend: * "descriptor" for descriptor auth * "intro" for into auth > We need your opinions about this. > Should we let the service enable one while disable the other? Yes, they have different security properties. For example, a Ricochet-like peer to peer messaging protocol would like to be able to revoke one contact (intro auth), without disconnecting all the rest (descriptor auth). > Or should we require the service to enable both for all clients? > > If you want to let the service be able to enable one while disable the > other, do you have any opinion on how to configure the torrc? If someone doesn't understand client auth in detail, and just wants to be more secure, we should give them a single option that enables both kinds of client auth. (Security by default.) OnionServiceClientAuthentication 1 (Default: 0) If someone knows they only want a particular client auth method, we should give them another option that contains a list of active client auth methods. (Describe what you have, not what you don't have, because negatives confuse humans.) OnionServiceClientAuthenticationMethods intro (Default: descriptor, intro) T___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
On 28 Apr 2018, at 05:56, nusenu wrote: >> And also we will be able to reduce the >> requirements for becoming an HSDir which will strengthen and make our >> network more robust. >> >> That said, I think we are unfortunately still far from deprecating v2 >> onions: > > > thanks for listing all these relevant ticket IDs, I pasted your email into > trac and I made them child tickets of > https://trac.torproject.org/projects/tor/ticket/25955 > > lets try to link all relevant tickets there Please don't, that confuses our workflow. A lot of these tickets are unrelated to v3 onion service features in Tor. If you want to link all these tickets somewhere, open another ticket. T ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
On 28 Apr 2018, at 04:48, Damian Johnson wrote: >> OnionBalance requires STEM support for V3 > > Hi Alec, would you mind clarifying what you need from Stem? As far as > I'm aware Stem supports v3 onion service creation... > > https://trac.torproject.org/projects/tor/ticket/25124 > > See the 'version 3' note at the end of... > > https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service > > I'm unaware of the ball being in my court on any v3 Onion Service > stuff. If there's something I should have on my radar then please let > me know! OnionBalance requires Stem support for v3 HSFETCH But Stem requires Tor support for v3 HSFETCH https://trac.torproject.org/projects/tor/ticket/25417 T___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onion v2 deprecation plan?
Hi nusenu, I've just finished catching up with this thread, ticket changes, and the IRC discussion overnight. > On 28 Apr 2018, at 09:30, teor wrote: > > On 28 Apr 2018, at 05:56, nusenu wrote: > >>> And also we will be able to reduce the >>> requirements for becoming an HSDir which will strengthen and make our >>> network more robust. >>> >>> That said, I think we are unfortunately still far from deprecating v2 >>> onions: >> >> >> thanks for listing all these relevant ticket IDs, I pasted your email into >> trac and I made them child tickets of >> https://trac.torproject.org/projects/tor/ticket/25955 >> >> lets try to link all relevant tickets there > > Please don't, that confuses our workflow. > A lot of these tickets are unrelated to v3 onion service features in Tor. > > If you want to link all these tickets somewhere, open another ticket. I'm sorry, that was what you did. But using the cyperpunks account made a few network team members nervous. When we see accounts we don't know making sweeping changes, we tend to revert them. That's what happened in this case. You're welcome to use the cuperpunks account for any changes, but please check with us next time before making large changes. In this case, I'm not sure if we want a parent ticket, or a tag. A tag might be more useful, because we use parent tickets for closely coupled tasks. And when there are too many layers of parents, people get confused. T ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal #291 Properties (was IRC meeting)
Mike Perry:
> teor:
> >
> >
> > > On 25 Apr 2018, at 18:30, Mike Perry wrote:
> > >
> > > 1. Hidden service use can't push you over to an unused guard (at all).
> > > 2. Hidden service use can't influence your choice of guard (at all).
> > > 3. Exits and websites can't push you over to an unused guard (at all)
> > > 4. DoS/Guard node downtime signals are rare (absent)
> > > 5. Nodes are not reused for Guard and Exit positions ("any" positions)
> > > 6. Information about the guard(s) does not leak to the website/RP (at
> > > all).
> > > 7. Relays in the same family can't be forced to correlate Exit traffic.
> >
> > I think this list is missing some important user-visible properties, or it's
> > not clear which property above corresponds to these properties:
> >
> > * Is Tor reliable and responsive when guards go down, or when I move
> > networks, or when I have lost and regained service?
>
> I think this is implicitly provided by #4. Downtime is a security issue.
> If (any of) a client Guard(s) are down, and the adversary can detect
> this based on client behavior, well, that is a side channel signal that
> provides information about the Guard. So by satisfying #4, we also
> satisfy the weaker conditions of general reliability and responsiveness.
>
> > I also think it's missing an implicit property, which we should make
> > explicit:
> >
> > * Can Tor users be fingerprinted by their set of guards or directory guards?
> >
> > Perhaps this property is out of scope.
>
> I think it is worth considering. We should add it if we need to do
> another round of evaluation.
Alright, for the sake of argument, let's call this Property #8:
8. Less information from guard fingerprinting (the least information)
I argue that this #8 is also equivalent to a #9 that Roger would ask
for:
9. Fewer points of observation into the network (the fewest points).
To avoid TL;DR, that argument is an exercise to the reader ;).
Here is a proposal that beats my previous proposal on Property #8 and
#9, while trying to preserve as many of the other properties as
possible:
* Set "num primary guards"=1 and "num primary guards to use"=1
* Set "num directory guards"=1 and "num directory guards to use"=1
* Don't give Exit nodes the Guard flag.
* Allow "same node, same /16, same family" between guard and last hop,
but only for HS circuits (which are at least 4 hops).
* Allow same /16 and same family for HS circuits.
* When a primary guard leaves the consensus, pick a new one.
* When a primary guard fails circuits, do $MAGIC_FAILURE_HEURISTIC.
This proposal gets strong:
1. Hidden service use can't push you over to an unused guard (at all).
2. Hidden service use can't influence your choice of guard (at all).
3. Exits and websites can't push you over to an unused guard (at all)
8. Less information from guard fingerprinting (the least information)
It loses #4 (and your reliability point above), because if we transition
to a second guard too quickly when the first one starts failing, then we
lose the winning fingerprinting property we want to keep. So then
therefore, we must tolerate failure and RESOURCELIMIT issues and suffer
through connectivity issues during DoS:
4. DoS/Guard node downtime signals are rare (absent)
It then gets us regular:
5. Nodes are not reused for Guard and Exit positions ("any" positions)
6. Information about the guard(s) does not leak to the website/RP (at all).
7. Relays in the same family can't be forced to correlate Exit traffic.
And again, we could get strong #6 if we allow the guard node for both RP
and the node before the RP:
6. Information about the guard(s) does not leak to the website/RP (at all).
So the key thing (in this property list) that forcing one guard causes us
to lose is reliability under DoS, which is a guard discovery vector (and
probably a source of other side channels, too).
--
Mike Perry
signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
