<span id="mailbox-conversation"><div id="orc-email-signature" style="display: block;"><div id="orc-email-signature">> Hidden Servers probably also have value in protecting servers from <span style="-webkit-tap-highlight-color: transparent;">getting taken down, or their operators harassed.</span> </div></div> <div id="orc-email-signature"><br></div> <div id="orc-email-signature">Definitely yes on the latter. It depends on what you mean by 'taken down' for the former: If you mean 'a legal authority ordering a service to be taken down' then yes. If you mean 'less susceptible to DOS attacks', then definitely not. (This is one of the downsides of HS; it's -- relatively -- trivial to permanently DOS a hidden service.</div> <div id="orc-email-signature"><br></div> <div id="orc-email-signature"> <div id="orc-email-signature">> They also allow the <span style="-webkit-tap-highlight-color: transparent;">server operator to claim that since the server can only be contacted</span> </div> <div id="orc-email-signature">over Tor, it's impossible for server to know much about its clients - <span style="-webkit-tap-highlight-color: transparent;">this might help avoid getting drawn into legal investigations.</span> </div> <div id="orc-email-signature"></div> </div> <span class="mailbox-inline-edit"></span><div>It (also?) minimizes the chances that an order granting access to ISP-kept IP-connection logs at the server's real endpoint would be proper.* (Alas, a lot of ISPs keep IP logs; see, e.g., [1].) This is a big privacy benefit for a Pond server (or other HS-only service) operator.<br><div id="orc-email-signature"> <div id="orc-email-signature"><span style="-webkit-tap-highlight-color: transparent;"><br></span></div> <div id="orc-email-signature"></div> </div> </div> <span class="mailbox-inline-edit">[1] </span><a href="http://cryptome.org/2014/06/verizon-stratfor-hack.pdf">http://cryptome.org/2014/06/verizon-stratfor-hack.pdf</a><div><div id="orc-email-signature"><div id="orc-email-signature"></div></div></div> <span class="mailbox-inline-edit"></span><div>*(Assuming that the third-party-doctrine in its strong form is wrong. In particular, there is a clear and cheap minimization strategy for discovery that doesn't disclose IP addresses.)</div></span><div class="mailbox_signature">—<br>Sent using alpine: an Alternatively Licensed Program for Internet News and Email</div> <br><br><div class="gmail_quote"><p>On Sat, Jun 14, 2014 at 4:31 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Some e2e messaging protocols make use of Tor Hidden Services. It's <br>interesting to think about what value this adds: <br><br>In Cables [1] and the (work-in-progress) SMTorP [2], recipients can <br>run their own Tor Hidden Service. So if you're online, messages can <br>be delivered directly to you without needing a mailbox server. <br><br>The downside: <br> - Tor Hidden Services are easier to de-anonymize than Tor clients, as <br>arbitrary traffic can be directed at them [3]. <br> - Traffic correlation between sender and receiver is easier than it <br>would be in a store-and-forward system. <br> - The recipient is advertising their online / offline status to <br>anyone who knows their address. <br> - Correlating sender traffic with the online/offline status of <br>potential recipients might be possible. Consider an attacker who can <br>monitor the sender's traffic profile. If the sender's traffic profile <br>suggests they are "polling" for a recipient until time T, then <br>delivering a message, that suggests the sender might be communicating <br>with a recipient whose hidden service came online shortly before time <br>T. <br><br>So a store-and-forward system with many users sharing the same mailbox <br>server seems better. This is how Pond works [4]. But Pond's mailbox <br>servers are *also* Hidden Servers. This may have some benefits, but <br>it doesn't seem necessary: <br><br>For user anonymity, users can contact their mailbox server and their <br>recipients' mailbox servers over Tor; Hidden Services aren't needed. <br><br>For unlinkability of users with each other, the correlation of packet <br>timing and sizes between sender and recipient needs to be broken. In <br>Pond, clients retrieve padded data from their mailbox server at a <br>roughly constant rate. Hidden Services don't help with this. <br><br>Hidden Servers might make it harder to do correlation of traffic <br>between sending clients and recipient *servers*, by making the <br>recipient server hard to locate. But if users choose servers run by <br>known parties, then this protection is lost. A better solution would <br>probably be high-latency-variance relays (remailers, mix network) <br>between sending clients and recipient servers. <br><br>Hidden Servers probably also have value in protecting servers from <br>getting taken down, or their operators harassed. They also allow the <br>server operator to claim that since the server can only be contacted <br>over Tor, it's impossible for server to know much about its clients - <br>this might help avoid getting drawn into legal investigations. <br><br>But it's interesting to note that Pond's dependence on Tor Hidden <br>Services is slight. <br><br>Trevor <br><br>[1] http://dee.su/cables <br>[2] https://github.com/pagekite/Mailpile/wiki/SMTorP <br>[3] http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf <br>[4] https://pond.imperialviolet.org/tech.html <br>_______________________________________________ <br>Messaging mailing list <br>Messaging@moderncrypto.org <br>https://moderncrypto.org/mailman/listinfo/messaging <br></p></blockquote></div><br>