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

Jacob Appelbaum <> Tue, 01 December 2015 00:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 100491B33D2 for <>; Mon, 30 Nov 2015 16:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8Tq6VDBeZQUC for <>; Mon, 30 Nov 2015 16:14:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D3881B33CF for <>; Mon, 30 Nov 2015 16:14:15 -0800 (PST)
Received: by iouu10 with SMTP id u10so195722347iou.0 for <>; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qy5+M/b75EHhR6zNdhxNv/78JN4Bgnh0It7R2zjzASo=; b=hLNTeaeGBre6Vzze21qgYFM7w88mfoXqRUp+YZUv7FUhV2lWEd/8YcY4ByckjM6iC5 KvtNklChD3odTSN6hjRSjFdBQRU8yAaqqzvntJD523JFVLjDAJyEDcu0XTGbOkMIbFbw zMNGOYGcBHZK8yfVX4a8Clh4KcsBhT7ei9KWqwxyeXxKlAjksJ9zqYdfilcWnN1jhWtU Ih7BZRRVXYyG/MQeSyQgqzIm7r79QMsJS9OQRXHgg4TVPoCb4riKZaff7OOeHrQbjn+a CcsFQJ6l/LVnbmgv6Yllff7IJ5e1m1DdbQZYOYFodg2cSw/oYJ7CiyWO7Kdd3g7QEWW1 Ahmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qy5+M/b75EHhR6zNdhxNv/78JN4Bgnh0It7R2zjzASo=; b=MlrlKcO+hySLEAJqY921yczHvBK8sQnVdpetiIUdUnTDR0GNwfFatPXLT1kpc0l3Qc +/xgjgqdCLtiXRVin49ZaYUXk0fDMIeOG4RjVeZLA+BTN9WoDi7/JY/zOCFzBRKbOdks 4Mmcm3jpSQs/vndFlqmuX9jAeetpygRqKKp/7yFqArVXqzpZBVVvxSbAnbpk/Dfz6mW0 d7iLJPLjTgDDvPI9PDu2i0crmnCOmqYPAdSfGJcphzQ/OvT2jxxJ3ukO/R9QdwUD9XXx gKl6sa2Ezu2qw2tgSZJJ30VNTC3UDlTtjGS6XmK6c8wUaoDbzUNaLuhon0iXvVJYicUF wQJg==
X-Gm-Message-State: ALoCoQmHfgLnAG9nswkot7hjMAKEBLHokZOpiQcDCbx0D+3/cHbfrY4mOl35khbeIpRPvfXUqnLy
MIME-Version: 1.0
X-Received: by with SMTP id l19mr53999655iod.138.1448928854627; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
Received: by with HTTP; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 01 Dec 2015 00:14:14 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Hubert Kario <>
Content-Type: text/plain; charset="UTF-8"
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: Tue, 01 Dec 2015 00:14:17 -0000

On 11/30/15, Hubert Kario <> wrote:
> On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
>> On 11/30/15 2:40 AM, Peter Gutmann wrote:
>> > Nikos Mavrogiannopoulos <> writes:
>> >> I believe your proposal is a nice example of putting the cart
>> >> before the horse. Before proposing something it should be clear
>> >> what do you want to protect from, what is the threat?
>> >
>> > Exactly.  If you want to thwart traffic analysis, you need to do
>> > something like what's done by designs like Aqua ("Towards Efficient
>> > Traffic-analysis Resistant Anonymity Networks"), or ideas from any
>> > of the other anti-traffic- analysis work that's emerged in the past
>> > decade or two.
>> I'm well aware of Aqua and "the other anti-traffic-analysis work
>> that's emerged in the past decade or two": in fact I led one of the
>> major recent systematic projects in that space.  See for example:
>> internet-panopticon/fulltext
>> > You get traffic
>> > analysis resistance by, for example, breaking data into fixed-length
>> > packets, using cover traffic, and messing with packet timings, not
>> > by
>> > encrypting TLS headers.
>> Packet padding and header encryption are both important, complementary
>> security measures: you get security benefits from each that you don't
>> get from the other.  Yes, you need padding to obtain systematic
>> protection from traffic analysis - when for whatever reason not all
>> implementations are always padding to the exact same standardized
>> record length, header encryption makes padded streams less trivially
>> distinguishable from unpadded streams, and makes streams with
>> different record sizes less trivially distinguishable from each
>> other.
> the header contains only one piece of information, and it is public
> already - the amount of data transmitted*

I'm pretty sure TLS has a lot more data...

> If you want to hide how much data was transmitted, you need to establish
> a tunnel that transmits data constantly, at the exact same rate for the
> whole duration of connection.


> that means that you need to know a). what bandwidth the client has, b).
> what bandwidth the server can spare and c). how much data the user wants
> to get or send to the server (I really don't want to transmit 1GiB of
> data over a 100KiB/s stream if I have a 100Mbps link...).


> this goes well past the TLS WG charter, if only because it requires very
> close cooperation with the application layer
> so while the padding mechanism should be there, we really can't describe
> how it needs to be used, as it can't be made universal nor is it
> necessary for all use cases

I think it should be described how it needs to be used...

>  * - sure, the record layer boundaries can tell something about the data
> being transmitted, but so can the presence of data transmission taking
> place in the first place (think of a station sending reports only when
> it detects something while keeping connection open the whole time)

Yes, they tell something and that something is better removed.

>> One thing that would greatly help Tor and all similar,
>> padded protocols is if they could "blend in" even just a little bit
>> better with the vast bulk of ordinary TLS-encrypted Web traffic, and
>> that's one of the big opportunities we're talking about here.
> the initial message in handshake in TLS MUST stay the same thus it is
> impossible to make it look like Tor. Not to thwart the Pervasive
> Monitoring threat of TLA agencies.

That Tor claim is strange and seemingly false in any case. Also, I've
said it before quoting the RFC but I'll say it again: Pervasive
Monitoring is an attack.

>> If you think it is practical for the TLS 1.3 standard to specify a
>> single, fixed record size that all implementations of TLS 1.3 must use
>> (i.e., explicitly freeze not only the version field but the length
>> field), then that would be great for traffic analysis protection and
>> on that basis I would support that proposal.  But that frankly seems
>> to me likely a bit too much to ask given the diversity of TLS
>> implementations and use-cases.  Tell me if you believe otherwise.
> That will just round up to a multiple of 256 bytes the data sizes
> transmitted. Hardly an improvement over the current 16 byte blocks.

Closer to 512 bytes is better.

All the best,