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

Henrick Hellström <> Sun, 29 November 2015 11:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 77AD41A0141 for <>; Sun, 29 Nov 2015 03:30:44 -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 p2O-yNwNb107 for <>; Sun, 29 Nov 2015 03:30:42 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 1C2751A013F for <>; Sun, 29 Nov 2015 03:30:41 -0800 (PST)
X-Halon-ID: 9d58d85a-968c-11e5-a960-00505692585a
X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Sun, 29 Nov 2015 12:30:38 +0100 (CET)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 13D0EC9378 for <>; Sun, 29 Nov 2015 12:30:38 +0100 (CET)
References: <> <> <>
From: Henrick Hellström <>
Message-ID: <>
Date: Sun, 29 Nov 2015 12:29:04 +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: Sun, 29 Nov 2015 11:30:44 -0000

On 2015-11-29 10:48, Bryan A Ford wrote:
> In short, leaving TLS headers in cleartext basically hands any
> eavesdropper a huge information side-channel unnecessarily and precludes
> anyone*but*  the TLS implementation itself from adding any traffic
> analysis protection into the system.  Encrypting TLS headers appears to
> cost practically nothing (at least if done as I've proposed), and it
> allows traffic analysis protection (whether weak or strong, intentional
> or unintentional) to be introduced at multiple points: e.g., by TLS
> itself, or by the TCP stack, or by middleboxes.

Thank you for the explanation. A few points:

The only way to completely thwart traffic analysis, is to always send 
data with the exact same amount-frequency pattern. The middleboxes you 
describe will *not* be able to achieve this, unless the TLS sender is 
adapted for such processing anyway.

The middleboxes can't inject data. All they can do is wait for data to 
arrive and delay data that has already arrived. Traffic analysis is 
about deriving information from patterns that emerge from the 
combination of timing and sizes. If data is delayed in order to reach a 
specific size before being forwarded, the middlebox might just be 
shifting the size signal to an equally detectable timing signal.

This is particularly true, if low latency is also a requirement. If very 
high latency is acceptable, the middleboxes might theoretically hide 
everything except the total amount of data transmitted during specific 
time intervals.