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

Henrick Hellström <> Sat, 28 November 2015 16:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BCF51B320B for <>; Sat, 28 Nov 2015 08:58:29 -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 LcYWF7wI96RO for <>; Sat, 28 Nov 2015 08:58:27 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 220D51B3209 for <>; Sat, 28 Nov 2015 08:58:26 -0800 (PST)
X-Halon-ID: 3c57eb69-95f1-11e5-b567-005056925495
X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Sat, 28 Nov 2015 17:58:23 +0100 (CET)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 66672C9378 for <>; Sat, 28 Nov 2015 17:58:23 +0100 (CET)
References: <> <> <> <> <>
From: Henrick Hellström <>
Message-ID: <>
Date: Sat, 28 Nov 2015 17:56:56 +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: 7bit
Archived-At: <>
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 16:58:29 -0000

On 2015-11-28 17:41, Roland Zink wrote:
>> 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?

AFAIK, HTTP 1.1 browsers typically don't send a new request over an open 
connection, before it has received the response to the previous request. 
If that is the case, it is trivial to get the message lengths from the 
traffic, with or without encrypted TLS record headers. IOW you gain 
nothing by encrypting the length fields.

>> 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.

You will have to make sure the peer is sending out a continuous stream 
of encrypted messages, anyway, or else you will not gain much by 
encrypting the TLS record headers. Relying on TLS fragments piling up at 
the TCP/IP level, rather than at the application level or TLS level, is 
not a reliable way to make traffic analysis harder. Even if the 
responses to a specific pair of requests pile up 999 times of 1000, 
there will still be a signal from the 1 in 1000 event that will be 
detectable by traffic analysis.