On 11/30/15, Hubert Kario <hka...@redhat.com> wrote:
> On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
>> 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.
>
> the header contains only one piece of information, and it is public
> already - the amount of data transmitted*
I'm pretty sure TLS has a lot more data...
> If you want to hide how much data was transmitted, you need to establish
> a tunnel that transmits data constantly, at the exact same rate for the
> whole duration of connection.
>
...
> that means that you need to know a). what bandwidth the client has, b).
> what bandwidth the server can spare and c). how much data the user wants
> to get or send to the server (I really don't want to transmit 1GiB of
> data over a 100KiB/s stream if I have a 100Mbps link...).
>
...
> this goes well past the TLS WG charter, if only because it requires very
> close cooperation with the application layer
>
> so while the padding mechanism should be there, we really can't describe
> how it needs to be used, as it can't be made universal nor is it
> necessary for all use cases
>
I think it should be described how it needs to be used...
> * - sure, the record layer boundaries can tell something about the data
> being transmitted, but so can the presence of data transmission taking
> place in the first place (think of a station sending reports only when
> it detects something while keeping connection open the whole time)
>
Yes, they tell something and that something is better removed.
>> 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.
>
> the initial message in handshake in TLS MUST stay the same thus it is
> impossible to make it look like Tor. Not to thwart the Pervasive
> Monitoring threat of TLA agencies.
That Tor claim is strange and seemingly false in any case. Also, I've
said it before quoting the RFC but I'll say it again: Pervasive
Monitoring is an attack.
>> 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.
>
> That will just round up to a multiple of 256 bytes the data sizes
> transmitted. Hardly an improvement over the current 16 byte blocks.
>
Closer to 512 bytes is better.
All the best,
Jacob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
