On 11/30/15 2:40 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos <n...@redhat.com> writes:
>
>> I believe your proposal is a nice example of putting the cart before the
>> horse. Before proposing something it should be clear what do you want to
>> protect from, what is the threat?
>
> Exactly. If you want to thwart traffic analysis, you need to do something
> like what's done by designs like Aqua ("Towards Efficient Traffic-analysis
> Resistant Anonymity Networks"), or ideas from any of the other anti-traffic-
> analysis work that's emerged in the past decade or two.
I'm well aware of Aqua and "the other anti-traffic-analysis work that's
emerged in the past decade or two": in fact I led one of the major
recent systematic projects in that space. See for example:
http://dedis.cs.yale.edu/dissent/
http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-an-internet-panopticon/fulltext
> You get traffic
> analysis resistance by, for example, breaking data into fixed-length
> packets, using cover traffic, and messing with packet timings, not by
> encrypting TLS headers.
Packet padding and header encryption are both important, complementary
security measures: you get security benefits from each that you don't
get from the other. Yes, you need padding to obtain systematic
protection from traffic analysis - when for whatever reason not all
implementations are always padding to the exact same standardized record
length, header encryption makes padded streams less trivially
distinguishable from unpadded streams, and makes streams with different
record sizes less trivially distinguishable from each other.
Padding-based transmission formats such as Aqua and Tor tend to specify
a single fixed packet size for *all* traffic using that protocol. For
example, the Tor protocol always uses 256-byte cells for everything.
This is for obvious indistinguishability reasons: e.g., if some versions
of Tor padded to 256 bytes while other versions padded to 512 bytes,
then it would be trivial for an adversary to distinguish the two. And
if the 512-byte version of Tor were fairly uncommon (either because it's
"too new" or "too old" or specific to a rare platform or whatever), then
the Tor streams using 512-byte cells would stick out obviously from
anyone else.
Furthermore, popular and well-designed as it is, Tor and similar
protocols have the well-known problem that it's pretty trivial for a
traffic analysis attacker to distinguish a Tor stream from any other
non-Tor stream. The severity of this weakness was put in sharp
perspective by the Harvard bomb hoax incident
(http://edition.cnn.com/2013/12/18/justice/massachusetts-harvard-hoax/).
And it's not in any way because Tor was poorly-designed: on the
contrary, the problem is Tor sticks out because it's a well-designed
traffic-analysis-resistant protocol sharply silhouetted against a
backdrop of traffic that makes no attempt at traffic analysis
protection. One thing that would greatly help Tor and all similar,
padded protocols is if they could "blend in" even just a little bit
better with the vast bulk of ordinary TLS-encrypted Web traffic, and
that's one of the big opportunities we're talking about here. But to
make that happen, we would need to either (a) specify that *all* TLS 1.3
implementations use the same standardized record length like Tor does,
or (b) if that's not practical, do whatever we can to make flows padded
to a particular size less obviously distinguishable from unpadded flows
or flows padded to a different size.
If you think it is practical for the TLS 1.3 standard to specify a
single, fixed record size that all implementations of TLS 1.3 must use
(i.e., explicitly freeze not only the version field but the length
field), then that would be great for traffic analysis protection and on
that basis I would support that proposal. But that frankly seems to me
likely a bit too much to ask given the diversity of TLS implementations
and use-cases. Tell me if you believe otherwise.
So on the assumption that TLS 1.3 might not be ready to jump "whole-hog"
into Aqua/Tor-style transmission protocols that standardize a single
constant record size, I believe that header encryption provides at least
a useful, weak but significant security improvement at negligible cost.
Sure, active attackers can still use "dribble attacks" (as discussed
recently on the SSH mailing list) to sniff out the record boundaries,
but they have to be active on-path and have to delay traffic, which
risks getting noticed. Many attackers in practice are passive (don't
have the option or just don't want to invest the resources for full
MITM), and/or don't want to risk getting noticed by fiddling with the
traffic in readily detectable ways.
Cheers
Bryan
>
> Peter.
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
