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

Hubert Kario <hkario@redhat.com> Mon, 30 November 2015 14:27 UTC

Return-Path: <hkario@redhat.com>
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 23B521ACE09 for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 06:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 BFc-G_jqto8k for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 06:27:36 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE681ACE05 for <tls@ietf.org>; Mon, 30 Nov 2015 06:27:36 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id B01503B70B; Mon, 30 Nov 2015 14:20:44 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-114.brq.redhat.com [10.34.0.114]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUEKghH023207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Nov 2015 09:20:43 -0500
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 30 Nov 2015 15:20:36 +0100
Message-ID: <2564045.EyFMgGcPZE@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.6-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <565C1DD8.20305@gmail.com>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92EA4@uxcn10-5.UoA.auckland.ac.nz> <565C1DD8.20305@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart10427855.uAeQSjQljr"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AmYGHwTFHdNuNqbGOqZPSCPN1CA>
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: Mon, 30 Nov 2015 14:27:38 -0000

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*

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

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

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic