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

Roland Zink <> Sat, 28 November 2015 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 02AC11B31B9 for <>; Sat, 28 Nov 2015 08:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OCKGrRfyFvO1 for <>; Sat, 28 Nov 2015 08:42:03 -0800 (PST)
Received: from ( [IPv6:2a01:238:20a:202:5300::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CCBD1B319D for <>; Sat, 28 Nov 2015 08:42:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1448728919; l=2290; s=domk;; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=/Vmm3LLImYY0OShHb0BM9MmbDV1K0L6HkhWmdKiPFzU=; b=Cuct/PZC/Rww28hIF1EBO5l2ab6qa4RacFT/oodZSMTlHMDcRPnDURYgUcLE//pHmBo M60LpA+vjP1nG9FkZO3/yubJbpsuTxqumhTXVWQNf+hEqu8+dXj5npxW2jv0hDG16xBg6 UWNmNSWbuzo5TP7+4UY/ngwC0oe4f4FmJtI=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLyDqLcHdRVpdc4pNvaGg0hjQJme/g==
Received: from [IPv6:2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc] ([2001:4dd0:ff67:0:24f5:116e:f0a9:dfcc]) by (RZmta 37.14 AUTH) with ESMTPSA id j00972rASGfxIAu (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <>; Sat, 28 Nov 2015 17:41:59 +0100 (CET)
References: <> <> <> <>
From: Roland Zink <>
Message-ID: <>
Date: Sat, 28 Nov 2015 17:41:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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:42:05 -0000

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