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

Jacob Appelbaum <jacob@appelbaum.net> Tue, 01 December 2015 00:14 UTC

Return-Path: <jacob@appelbaum.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100491B33D2 for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 16:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Tq6VDBeZQUC for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 16:14:15 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3881B33CF for <tls@ietf.org>; Mon, 30 Nov 2015 16:14:15 -0800 (PST)
Received: by iouu10 with SMTP id u10so195722347iou.0 for <tls@ietf.org>; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=appelbaum-net.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.107.137.19 with SMTP id l19mr53999655iod.138.1448928854627; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
Received: by 10.79.70.71 with HTTP; Mon, 30 Nov 2015 16:14:14 -0800 (PST)
X-Originating-IP: [199.87.154.251]
In-Reply-To: <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> <565C1DD8.20305@gmail.com> <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com>
Date: Tue, 01 Dec 2015 00:14:14 +0000
Message-ID: <CAFggDF0yyMP3ErgHjNKbF1Nu3CUutCXaay+e0vEMOiDNNbKSLQ@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: Hubert Kario <hkario@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/l9EInvyZC51a99S54YD81J1HYYk>
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 00:14:17 -0000

On 11/30/15, Hubert Kario <hkario@redhat.com> 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 <nmav@redhat.com> 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:
>>
>> 	http://dedis.cs.yale.edu/dissent/
>> 	http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-an->
>> 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,
Jacob