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

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

On 2015-11-28 12:30, Kriss Andsten wrote:
> On 27 Nov 2015, at 17:21, Henrick Hellström <[e-mail]> wrote:
>
>> How, exactly, would this be significantly harder? The adversary will still be able to tell when, and how much, TCP/IP data is sent between the peers. If there happens to be a revealing TLS record boundary in the middle of a TCP/IP packet, it would seem to me there is an implementation problem rather than a problem with the abstract protocol.
>
> This is actually quite common. Even when it does align with packet boundaries, it is providing known information rather than inferred information ("here's a length X blob, then a length Y blob" vs "Here's a bunch of packets whose lengths minus TLS headers amount to to X+Y").

Maybe I have missed something, but this seems awfully implementation 
dependent to me. Let's take a more specific example:

Suppose a web server is serving a request for a web page, which 
typically means that the client firstly sends a single HTTP request for 
the HTML page, and then multiple requests for the css, images, etc in a 
row.

Most times, the latter row of requests could easily be encoded in a 
single TLS fragment. This means that the server will become aware of all 
of the requests at the same time, and might encode all of the HTTP 
responses before beginning to encode the TLS fragments.

Carefully implemented, such a solution would not necessarily require 
significantly more resources to handle pipe-lining, compared to an 
alternative solution that would serve, encode and send the responses 
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP queue.