Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Henrick Hellström <[e-mail]>]

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.