Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points
Hello there, we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2]. On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step. I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not. Here are some issues that make this proposal not an obvious pick: 1) Security issues - Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further. That said we could potentially increase the number of intro points by doing proposal 246, and at the same time we could also increase their lifetime period to multiple days (instead of the current 18-24 hours lifetime), to keep the exposure of hidden services to an acceptable value. - It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor. 3) Load balancing issue - With proposal 246, the Tor network decides which relays will be used as the introduction points of a hidden service. A hidden service cannot pick its own introduction points, similarly to how currently a hidden service cannot pick its own HSDirs. This is a problem because it blocks load balancing solutions like onionbalance from working. Variants of the onionbalance logic can still work as suggested in the proposal [5], at the cost of increased engineering and sysadmin complexity. - Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246. 2) Reachability issue A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points. However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse? Personally, I'm not that concerned about the security issues I outlined above. I think the security difference will not be that great, and maybe we can equalize it by using some of the listed solutions. However, more thinking is required. I'm currently more concerned about the load balancing and reachability issues that I outlined above and maybe others that I forget. I would like to have more assurance that relay churn will not cause reachability issues to the proposal 246 system before we commit to it. Feedback is very welcome. Also please post any issues that I forgot to mention. We should try to figure out what to do here as soon as possible. If we fail to come to a conclusion here, our engineering plan is to ignore proposal 246 and continue with proposal 224 like it never happened. Of course this will suck if we later decide that proposal 246 was super important and should have happened. Cheers! [1]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html [2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html [3]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html [4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html [5]: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-and...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I am not a big fan of prop 246. I don't have a mindblowing counter argument that it's bad in some way, but I don't like the tradeoffs vs benefits ratio so much. It is a small performance improvement indeed, so clients will not cache descriptors and have to create 1 circuit instead of 2 before the rendezvous circuit but I don't think this is a big problem anyway. Hidden service servers use circuits to publish their descriptors to the corresponding HSDirs and close them without having to do it again too soon if nothing changes and also keep the circuits to the introduction points alive for a random number of INTRODUCE2 cells or amount of time, again not having to create new ones very soon. Proposal 250 is a major step forward in making HSDirs less dangerous and eliminates some attacks. I am super happy we have it ready that fast. I am also slightly uncomfortable that under prop 246 I must keep open a long lived circuit to relays not of my choice (merged HSDir + IP decided network wide based on shared randomness value). And I have to do it regardless how many INTRODUCE2 cells I get through them and for a mostly fixed amount of time. This is also a bullet in the head for hidden service popularity leaks if the HSDir+IP can identify the service (knows the unblinded key). A merged HSDir + IP knows the popularity of a hidden service with a very low error margin in this case (say $LEARNED_POPULARITY * 6 = $POPULARITY). In current design introduction points see a random number of INTRODUCE cells from 16k to 32k. Obviously a spying introduction point can assume that a hidden service is popular if it received 18000 introductions in 2 hours for example... but it's a difference between assuming something with a somewhat error margin and having some very precise figures. Load balancing is also a problem. Without prop 246 load balancing is shared, the HSDirs serve the descriptors and other relays act as introduction points (and are rotated), but will the same set of relays be able to handle both of these (and not just for one hidden service, but for multiple at the same time)? The amount of traffic experienced by introduction points is significantly bigger than the amount of traffic experienced by HSDirs given one hidden service (noticed this back when we tested onionbalance) so rotating introduction points as we currently do is a sane thing to do from this point of view. True that we have some amazing weighted hash ring suggestions, but concentrating too much information and traffic into highest bandwidth relays in the network doesn't sound attractive because as we an attacker doesn't need to physically seize a relay for some attacks to work - he can just watch upstream for some traffic correlations attacks to work. Being able to tweak the number of introduction points at hidden service server side is helpful for increasing capacity and load balancing. Disabling this option will cause problems in the future, because a network wide param setting the introduction points for all hidden services regardless their popularity or need doesn't sound attractive. After prop 250, a malicious HSDir can not do so much, but a merged HSDir + IP can for example kill the circuit and force the hidden service to rebuild it. Under the current design, we retry for some times and give up if an introduction point is unreliable, but with 246 we have to retry much more. If the same attacker also holds a reasonable % of middle bandwidth fraction in the Tor network, it will at least perform a successful guard discovery over the hidden service which is terrible. This may be fixed by not retrying a HSDir+IP too many times as described in section 4.3 of the proposal, but it will automatically lead to a capacity decrease (we have 5 HSDir + IP left out of 6). All these might not mean too much, but I am inclined to say prop 246 doesn't offer us too many benefits. I do like it very much that prop 246 will make clients to stop caching descriptors and hidden services be dependent on less relays overall - I am only double thinking if it's worth it or not. Looking forward to read comments from others as well. Thanks! On 1/13/2016 6:50 PM, George Kadianakis wrote:
Hello there,
we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2].
On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step.
I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not.
Here are some issues that make this proposal not an obvious pick:
1) Security issues
- Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further.
That said we could potentially increase the number of intro points by doing proposal 246, and at the same time we could also increase their lifetime period to multiple days (instead of the current 18-24 hours lifetime), to keep the exposure of hidden services to an acceptable value.
- It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor.
3) Load balancing issue
- With proposal 246, the Tor network decides which relays will be used as the introduction points of a hidden service. A hidden service cannot pick its own introduction points, similarly to how currently a hidden service cannot pick its own HSDirs.
This is a problem because it blocks load balancing solutions like onionbalance from working. Variants of the onionbalance logic can still work as suggested in the proposal [5], at the cost of increased engineering and sysadmin complexity.
- Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246.
2) Reachability issue
A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points.
However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse?
Personally, I'm not that concerned about the security issues I outlined above. I think the security difference will not be that great, and maybe we can equalize it by using some of the listed solutions. However, more thinking is required.
I'm currently more concerned about the load balancing and reachability issues that I outlined above and maybe others that I forget. I would like to have more assurance that relay churn will not cause reachability issues to the proposal 246 system before we commit to it.
Feedback is very welcome. Also please post any issues that I forgot to mention.
We should try to figure out what to do here as soon as possible.
If we fail to come to a conclusion here, our engineering plan is to ignore proposal 246 and continue with proposal 224 like it never happened. Of course this will suck if we later decide that proposal 246 was super important and should have happened.
Cheers!
[1]: https://lists.torproject.org/pipermail/tor-dev/2016-January/010182.html
[2]: https://lists.torproject.org/pipermail/tor-dev/2015-October/009762.html
[3]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009093.html
[4]: https://lists.torproject.org/pipermail/tor-dev/2015-July/009163.html
[5]: https://gitweb.torproject.org/torspec.git/tree/proposals/246-merge-hsdir-and... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBCAAGBQJWlrasAAoJEIN/pSyBJlsRTyEH/3jE+B+IN1AJr/w8aaRKdJST zG1t6dlPeSMljD+UoIoXWEaTluNmWgAEEZ83FxbSluHOM+C0EuUDHa6MgY2P5uqP XEVRbcXbYI9YpP6LHlqB+T93FJ4e0eFv8eDI+wTHI+nWeXFrGhVMJqWkbuNFqBlK LyxVaJBerKHa3C8Oeq/++fQeDr+9254pMpsto89yAo71+capIH26nyu0Jmm2UaCt Gwm3D8Gq4/vld8qEcwnl8dglg4t3wPlOboaSnOmp0FP4XZ9lXfGFCzTdCpYGC0MV Zb62pO4OXFtzyM+Z5K0EUN2WSop/SFtFOiDghB42hjS9gN6P89ccQB8Q0lcZe+U= =96nK -----END PGP SIGNATURE-----
On 13/01/16 20:42, s7r wrote:
After prop 250, a malicious HSDir can not do so much, but a merged HSDir + IP can for example kill the circuit and force the hidden service to rebuild it. Under the current design, we retry for some times and give up if an introduction point is unreliable, but with 246 we have to retry much more. If the same attacker also holds a reasonable % of middle bandwidth fraction in the Tor network, it will at least perform a successful guard discovery over the hidden service which is terrible. This may be fixed by not retrying a HSDir+IP too many times as described in section 4.3 of the proposal, but it will automatically lead to a capacity decrease (we have 5 HSDir + IP left out of 6).
The countermeasures in section 4.3 could be problematic for mobile hidden services, which have unreliable internet connections and therefore lose their intro circuits frequently. A service that lost its internet connection more than INTRO_RETRIES times in a consensus period would be left with no introduction points. The discussions on guard selection have suggested that clients can't easily distinguish between relay failures and internet connection failures. On Android the OS broadcasts connectivity events that could be used to reset the retry counter via the control port, but I don't know about other platforms. Cheers, Michael
Hi, I also have concerns about proposal 246, I don't think its benefits are compelling compared with the number of drawbacks. If we do want to skip the introduction point, proposal 252 (single onion services) provides a way for onion services to do this on an opt-in basis. (However, it doesn't allow onion services to skip the introduction point step and stay location-hidden.) There's also nothing preventing us from making this change in future, by modifying how hidden services select their introduction points. We could then teach clients to use the HSDir as an introduction point if it's in the list.
On 14 Jan 2016, at 03:50, George Kadianakis <desnacked@riseup.net> wrote:
Hello there, ... Here are some issues that make this proposal not an obvious pick:
1) Security issues ... - It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor.
As far as I recall, there was no guarantee that a large hidden service would not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the reachability of that hidden service for that period.
3) Load balancing issue ... - Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246.
It could also become a big problem for large hidden services which benefit from 10 (or more) introduction points.
2) Reachability issue
A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points.
However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse?
Proposal 246 makes it worse, because now both HSDirs and introductions depend on a potentially churning hash ring. If churn makes an introduction point unreachable, this increases the load on the other introduction points. Clients also cache descriptors from HSDirs, but they need an introduction point to be up whenever they contact the hidden service. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown - teor <teor2345@gmail.com> writes:
Hi,
Hi, thanks for the feedback.
I also have concerns about proposal 246, I don't think its benefits are compelling compared with the number of drawbacks.
To better understand the performance benefits of prop246, here are some experimental graphs by Karsten that show how much time each hidden service connection substep takes: http://ec2-54-92-231-52.compute-1.amazonaws.com/ As you can see the "fetch descriptor" step (which prop246 removes) is one of the most lengthy ones.
If we do want to skip the introduction point, proposal 252 (single onion services) provides a way for onion services to do this on an opt-in basis. (However, it doesn't allow onion services to skip the introduction point step and stay location-hidden.)
Yeah, SOS is not suitable for all the threat models we are trying to cover.
There's also nothing preventing us from making this change in future, by modifying how hidden services select their introduction points. We could then teach clients to use the HSDir as an introduction point if it's in the list.
Hm, maybe. But with increased migration and engineering costs.
On 14 Jan 2016, at 03:50, George Kadianakis <desnacked@riseup.net> wrote:
Hello there, ... Here are some issues that make this proposal not an obvious pick:
1) Security issues ... - It was also pointed out that the HSDir algorithm does not take into account the bandwidth of the nodes, making it easier to launch Sybil attacks. However, the rest of the the mailing list thread suggests various ways to do bandwidth weighted hash ring selections [4], so this might not be an important factor.
As far as I recall, there was no guarantee that a large hidden service would not pick 6 low-bandwidth HSDirs/IPs for a day, with serious impact on the reachability of that hidden service for that period.
3) Load balancing issue ... - Another concern here is that hidden services would not be able to change the number of their introduction points. This is not a big problem currently, but it could become in the future if the network gets more overloaded. As a partial solution to this, #17690 suggests making the number of HSDirs a network-wide consensus parameter that could also be used by proposal 246.
It could also become a big problem for large hidden services which benefit from 10 (or more) introduction points.
2) Reachability issue
A final issue here is that if the relay churn of the network increases, the introduction point hash ring might be changing rapidly and clients might get pointed to the wrong introduction points.
However, this does not seem like a greater problem than what hidden services are facing with HSDir reachability currently. Is this right, or does prop246 makes it worse?
Proposal 246 makes it worse, because now both HSDirs and introductions depend on a potentially churning hash ring. If churn makes an introduction point unreachable, this increases the load on the other introduction points.
Isn't that also the case for HSDirs currently?
Clients also cache descriptors from HSDirs, but they need an introduction point to be up whenever they contact the hidden service.
George Kadianakis:
Hello there,
we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2].
On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step.
I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not.
Here are some issues that make this proposal not an obvious pick:
1) Security issues
- Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further.
An additional related security issue is the traffic analysis benefits of separating out hsdir, IP, and RP. Recall that the original onion routing design did this on purpose (despite considerable performance drawback), so that actual circuit-level traffic patterns from the hidden service would be fully decoupled from their identity information. If we were to merge hsdirs with intro points that have long-lived circuits opened to them, we create additional point where an adversary who sees/learns/knows the hs address can attempt to passively or actively correlate traffic patterns with a malicious hidden service guard. There will be much more traffic available at the intropoint for such passive or active traffic analysis than there will be during a simple hsdir fetch or post, which means that long-term traffic analysis and related intersection/statistical disclosure attacks have much more opportunity to succeed. Long-term traffic analysis is also much harder to combat with padding. Granted, even with prop 224, an adversary that knows a non-authenticated hidden service address can decrypt the descriptor to learn the introduction points, but to actually be in the position to perform circuit-level traffic analysis on them requires another c/n multiplier, making the full attack succeed with probability O((c/n)^3) (ie, the adversary has to get in the guard, hsdir, and intropoint positions to be fully successful). I think this is reason enough to reject Proposal 246 for high security onion services by itself, but the complications with onionbalance also concern me, as well. -- Mike Perry
It's me again. It looks like I'm still the Internet champion of "Thinking once and posting twice". Mike Perry:
George Kadianakis:
Hello there,
we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2].
On this note, one of the open design issues that we need to tackle next is whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro Points into a single entity to simplify the protocol and improve its performance. The idea is that HSes will pick their intro points using the hash ring algorithm currently used for picking HSDirs. Clients will do the same and connect directly to the intro points instead of going through the HSDir step.
I suggest you read the proposal and the discussion thread to become better informed about this idea: https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
Proposal 246 changes the hidden service protocol substantially, which is why we need to decide whether to do it soon. The next steps in our implementation plan heavily depend on whether we will do proposal 246 or not.
Here are some issues that make this proposal not an obvious pick:
1) Security issues
- Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further.
An additional related security issue is the traffic analysis benefits of separating out hsdir, IP, and RP. Recall that the original onion routing design did this on purpose (despite considerable performance drawback), so that actual circuit-level traffic patterns from the hidden service would be fully decoupled from their identity information.
If we were to merge hsdirs with intro points that have long-lived circuits opened to them, we create additional point where an adversary who sees/learns/knows the hs address can attempt to passively or actively correlate traffic patterns with a malicious hidden service guard. There will be much more traffic available at the intropoint for such passive or active traffic analysis than there will be during a simple hsdir fetch or post, which means that long-term traffic analysis and related intersection/statistical disclosure attacks have much more opportunity to succeed. Long-term traffic analysis is also much harder to combat with padding.
Granted, even with prop 224, an adversary that knows a non-authenticated hidden service address can decrypt the descriptor to learn the introduction points, but to actually be in the position to perform circuit-level traffic analysis on them requires another c/n multiplier, making the full attack succeed with probability O((c/n)^3) (ie, the adversary has to get in the guard, hsdir, and intropoint positions to be fully successful).
This paragraph is wrong. Of course, the adversary can just poll the hsdir themselves actively to learn the current into points. It's still O((c/n)^2). Embarrassing.
I think this is reason enough to reject Proposal 246 for high security onion services by itself, but the complications with onionbalance also concern me, as well.
I think my traffic analysis concerns still stand, though. I'm especially nervous about having the IP lifetimes fixed at the same lifespan as the hsdirs. It would be better if we're able to shorten those as we better understand the benefits of padding and the risks of traffic analysis here. One option might be leaving Prop 246 as an optional later optimization. If we don't change the 224 crypto at all to optimize it for 246, we can still save the same number of network round trips if clients know to re-use their hsdir circ to perform the intro request if one of the listed intro points happens to be the current hsdir. That way we save the same number of round trips if we want, but don't lock ourselves in to this path restriction and associated circuit lifespan issue? Sure, we'd be doing a little bit of needless crypto, but the important thing is we can still save the network round trips and circuit construction. -- Mike Perry
Mike Perry <mikeperry@torproject.org> writes:
George Kadianakis:
Hello there,
we recently finished implementing proposal 250 which is one of the first steps for the upcoming hidden service redesign [1]. The next steps are implementing proposal 224 and the other performance and security proposals [2].
<snip>
1) Security issues
- Professor Hopper pointed out [3] that this proposal will double the number of introduction points of a hidden service (from the current 3 to 6). Introduction points have slightly more attack vectors than HSDirs, so we should not increase their number without analyzing further.
An additional related security issue is the traffic analysis benefits of separating out hsdir, IP, and RP. Recall that the original onion routing design did this on purpose (despite considerable performance drawback), so that actual circuit-level traffic patterns from the hidden service would be fully decoupled from their identity information.
If we were to merge hsdirs with intro points that have long-lived circuits opened to them, we create additional point where an adversary who sees/learns/knows the hs address can attempt to passively or actively correlate traffic patterns with a malicious hidden service guard. There will be much more traffic available at the intropoint for such passive or active traffic analysis than there will be during a simple hsdir fetch or post, which means that long-term traffic analysis and related intersection/statistical disclosure attacks have much more opportunity to succeed. Long-term traffic analysis is also much harder to combat with padding.
It's interesting that you say this, because reducing traffic fingerprinting vectors was one of the claimed advantages of proposal 246. From the proposal: Hidden services are able to stay online by simply maintaining their introduction circuits; there is no longer a need to periodically update descriptors. This reduces network load and traffic fingerprinting opportunities for a hidden service. To better understand the various attacks, here are some adversaries that we could consider: - Sybil adversary (HSDir + Guard): Seems to me that proposal 246 does slightly better than the status quo against a Sybil attacker who runs HSDirs and guards and tries to deanonymize hidden services or clients that first connect to the HSDir and then to the hidden service. I say this because proposal 246 only needs 6 HSDirs/IPs, whereas we currently need 6 HSDirs plus 3 IPs. So a Sybil attack is going to succeed sooner as it is now. I'm not sure why you are saying that we create additional monitoring points here. It seems prop246 is reducing them from 9 to 6. But maybe we are thinking of different attacks. FWIW, in prop246 after a client connects to the HSDir/IP, it first fetches the encrypted descriptor of the HS (BEGIN_DIR), it then sends an INTRODUCE1 cell, and then receives an INTRODUCE_ACK. This is one more step than the current protocol, which I guess is good for blending in because the INTRODUCE1 and INTRODUCE_ACK dance is quite distinguishable. However, tbh I doubt that the BEGIN_DIR step will make a big difference against a distinguishing attacker. - Network adversary (HS data center) Against a network attacker who monitors the data center of the hidden service, I think prop246 copes about the same as the current situation, considering the attack vectors from the USENIX paper (noticing the flow of INTRODUCE1 and INTRODUCE_ACK cells). Were you talking about a different adversary?
Granted, even with prop 224, an adversary that knows a non-authenticated hidden service address can decrypt the descriptor to learn the introduction points, but to actually be in the position to perform circuit-level traffic analysis on them requires another c/n multiplier, making the full attack succeed with probability O((c/n)^3) (ie, the adversary has to get in the guard, hsdir, and intropoint positions to be fully successful).
I think this is reason enough to reject Proposal 246 for high security onion services by itself, but the complications with onionbalance also concern me, as well.
Yes, I think I agree with this evaluation for now. Seems prop246 is more complicated than we can handle, and we should probably postpone it, except if someone can analyze it well soon.
On Jan 16, 2016, at 4:52 AM, George Kadianakis <desnacked@riseup.net> wrote:
Yes, I think I agree with this evaluation for now. Seems prop246 is more complicated than we can handle, and we should probably postpone it, except if someone can analyze it well soon.
I agree. There are too many open questions with proposal 246 to plan on implementing it in the same timeframe as we’re working on proposal 224. I suggest we change the proposal status to ‘Needs-Research’, and plan to gather all of these comments and make a real analysis of the tradeoffs at some later point. - special
On 16 Jan (16:21:30), John Brooks wrote:
On Jan 16, 2016, at 4:52 AM, George Kadianakis <desnacked@riseup.net> wrote:
Yes, I think I agree with this evaluation for now. Seems prop246 is more complicated than we can handle, and we should probably postpone it, except if someone can analyze it well soon.
I agree. There are too many open questions with proposal 246 to plan on implementing it in the same timeframe as we’re working on proposal 224.
I suggest we change the proposal status to ‘Needs-Research’, and plan to gather all of these comments and make a real analysis of the tradeoffs at some later point.
I second that. This thread outlines enough concerns to put this proposal back in research mode. Here is the commit torspec for that change. Please _NACK_ if you are unhappy with it else in a day or so I'll push this. https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=prop246-res... Cheers! David
- special
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 18 Jan (10:23:08), David Goulet wrote:
On 16 Jan (16:21:30), John Brooks wrote:
On Jan 16, 2016, at 4:52 AM, George Kadianakis <desnacked@riseup.net> wrote:
Yes, I think I agree with this evaluation for now. Seems prop246 is more complicated than we can handle, and we should probably postpone it, except if someone can analyze it well soon.
I agree. There are too many open questions with proposal 246 to plan on implementing it in the same timeframe as we’re working on proposal 224.
I suggest we change the proposal status to ‘Needs-Research’, and plan to gather all of these comments and make a real analysis of the tradeoffs at some later point.
I second that.
This thread outlines enough concerns to put this proposal back in research mode. Here is the commit torspec for that change. Please _NACK_ if you are unhappy with it else in a day or so I'll push this.
https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=prop246-res...
I got a ACK from asn yesterday and no NACK. This proposal is officially back in "Need-Research" status and this email thread has been referenced in the proposal (like you can see in the commit above). See torspec master: commit a4053594a34b141c5f05af54a7d15f1bf22952d9 Cheers! David
Cheers! David
- special
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (7)
-
David Goulet -
George Kadianakis -
John Brooks -
Michael Rogers -
Mike Perry -
s7r -
Tim Wilson-Brown - teor