Re: [liberationtech] Why_can't_email_be_secure
At 01:40 PM 8/25/2013, coderman wrote:
and to StealthMonger's point about latest generation mix networks for best privacy, why not instead focus on building low latency protocols that are resistant to traffic analysis and confirmation?
Because "low latency protocols that are resistant to traffic analysis" is a really really hard problem. Even doing "high latency protocols that are resistant to traffic analysis" is a really hard problem. "Building" them is a mere application of sufficiently advanced technology, right?
make them datagram based; utilize user space stacks
Datagrams don't give you any useful anonymity, because any decent ISP is going to block forged-source packets, but they do give you a bit more flexibility about timing, which is important for defending against traffic analysis. The standard warning about using them for an application is that it's extremely tempting to use them to reinvent TCP badly, because TCP really does a lot of things you want, and in a security context it's tempting to also reinvent TLS badly. Some other problems with them are that you need to get firewalls to allow them through, unless you disguise them as other protocols like the horribly evil things Dan Kaminsky regularly does to DNS, and if you don't disguise them then they stick out like a sore thumb on any IDS or netflow analyser. And if you're the only person using that protocol, you're not hiding from traffic analysis. It's a lot easier to hide if you implement your datagrams as http/https transactions of some kind, but building a bunch of relay nodes to pass those transactions along ends up reinventing Tor. Putting them in user space is just fine and mostly more portable. It's hard to get millisecond-level latency if you do that, but you can't hide from traffic analysis with latency that low anyway.
On Sun, Aug 25, 2013 at 10:52 PM, Bill Stewart <bill.stewart@pobox.com> wrote:
... Because "low latency protocols that are resistant to traffic analysis" is a really really hard problem. Even doing "high latency protocols that are resistant to traffic analysis" is a really hard problem.
the best kind of problems!
Datagrams don't give you any useful anonymity,
correct. i mention them as a prerequisite for both protection and usability. protection for example, with end-to-end SCTP multi-homed endpoints via userspace stacks would avoid predecessor attacks - if you block one route there are others which transit traffic, maintaining an uninterrupted session across otherwise individually volatile paths. usability for example to support UDP traffic and applications which are not currently served via TCP and connection oriented services.
... The standard warning about using them for an application is that it's extremely tempting to use them to reinvent TCP badly,
sadly, even TCP re-invented in user space is insufficient. you want a specific protocol implementation of multi-homed SCTP in userspace, probably on top of other protocol supports like LEDBAT or AQM. perhaps using ORCHID IPv6 identifiers for endpoint addressing. lot's of options; and as you said: it's a hard problem!
Some other problems with them are that you need to ... disguise them as other protocols.
this is a separate problem. for the core transport encapsulation in UDP may be sufficient. for censorship avoidance you will likely need to bounce over a DUST like path first to access such an anonymizing network. topology is an interesting subject, as the design must be decentralized but may not need to be homogenous.
Putting them in user space is just fine and mostly more portable. It's hard to get millisecond-level latency if you do that, but you can't hide from traffic analysis with latency that low anyway.
you want variable latency at the datagram level (e.g. stochastic reordering and shaping of traffic, with prioritization done at the endpoint where flows are visible.) more than the utmost in performance. as long as it is overall TCP fair of course :) and this is just the start. we haven't touched on network discovery, path awareness/selection/weighting, etc. as you said, hard problems; the best kind of problems!
participants (2)
-
Bill Stewart -
coderman