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

[Roland Zink <[e-mail]>]

Am 28.11.2015 um 13:05 schrieb Henrick Hellström:
> 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.
Even if it could be encoded in a single TLS fragment a simple minded 
browser may encode it one by one. Also there are many more use cases 
where such optimization may not work. Can you provide data what browsers 
are actually doing for HTTP/1.1 and HTTP2?
>
> 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.
>
I think it is more complicated so it will use more resources. You have 
to weight what is more important, the additional "security" or the 
"overhead". Anyway I thought the decision was to hide the record length.

Regards,
Roland