On 2015-11-29 10:48, Bryan A Ford wrote:
In short, leaving TLS headers in cleartext basically hands any
eavesdropper a huge information side-channel unnecessarily and precludes
anyone*but* the TLS implementation itself from adding any traffic
analysis protection into the system. Encrypting TLS headers appears to
cost practically nothing (at least if done as I've proposed), and it
allows traffic analysis protection (whether weak or strong, intentional
or unintentional) to be introduced at multiple points: e.g., by TLS
itself, or by the TCP stack, or by middleboxes.
Thank you for the explanation. A few points:
The only way to completely thwart traffic analysis, is to always send
data with the exact same amount-frequency pattern. The middleboxes you
describe will *not* be able to achieve this, unless the TLS sender is
adapted for such processing anyway.
The middleboxes can't inject data. All they can do is wait for data to
arrive and delay data that has already arrived. Traffic analysis is
about deriving information from patterns that emerge from the
combination of timing and sizes. If data is delayed in order to reach a
specific size before being forwarded, the middlebox might just be
shifting the size signal to an equally detectable timing signal.
This is particularly true, if low latency is also a requirement. If very
high latency is acceptable, the middleboxes might theoretically hide
everything except the total amount of data transmitted during specific
time intervals.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
