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

[Bryan A Ford <[e-mail]>]

On 11/29/15 12:29 PM, Henrick Hellström wrote:
> 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.

Very true.  But perfect traffic analysis protection isn't the only goal
of interest, and is usually impractical anyway.  A less ambitious but
still worthwhile goal is simply to make sure that in
imperfectly-protected connections, transmission bursts leak as little of
their internal structure as possible even though the timing and burst of
the (whole) burst will still inevitably risk leaking something.  Even
when it's impractical to leak nothing, it's still worthwhile to leak less.

A fairly important common-case example of this, I think, is Web page
loads in which the client submits a bunch of requests in parallel over
the same connection.  This was never widely enabled in HTTP/1.1 due to
compatibility concerns but will probably become the norm quickly with
HTTP/2.0.  A TLS implementation designed without much concern for
traffic analysis will probably send those multiple small
requests/replies in separate TLS records, giving eavesdroppers a nice
fine-grained fingerprint of what all is in that transmission burst.  If
TLS 1.3 hides its headers, then either the TLS implementation, the TCP
stack, or a middlebox could readily scrub that internal structure and at
least make life harder for the attacker (e.g., reduce the bandwidth of
the side-channel).  That seems worthwhile to me if it doesn't cost much.

Cheers
Bryan