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

Henrick Hellström <> Sat, 28 November 2015 12:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E8ABA1ACEA5 for <>; Sat, 28 Nov 2015 04:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.95
X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RCY3_ouoxbCs for <>; Sat, 28 Nov 2015 04:06:57 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 6DC8C1ACEA4 for <>; Sat, 28 Nov 2015 04:06:55 -0800 (PST)
X-Halon-ID: 82c59eda-95c8-11e5-a259-005056921986
X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP; Sat, 28 Nov 2015 13:06:51 +0100 (CET)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id B4DC8C9378; Sat, 28 Nov 2015 13:06:51 +0100 (CET)
References: <> <> <>
To: Kriss Andsten <>
From: Henrick Hellström <>
Message-ID: <>
Date: Sat, 28 Nov 2015 13:05:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Nov 2015 12:06:59 -0000

On 2015-11-28 12:30, Kriss Andsten wrote:
> On 27 Nov 2015, at 17:21, Henrick Hellström <> 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 

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.