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
- [TLS] Encrypting record headers: practical for TL… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Tony Arcieri
- Re: [TLS] Encrypting record headers: practical fo… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bill Cox
- Re: [TLS] Encrypting record headers: practical fo… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Short, Todd
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Jim Schaad
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… John Mattsson
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- [TLS] Fully encrypted and authenticated headers (… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Fully encrypted and authenticated heade… Martin Thomson
- Re: [TLS] Fully encrypted and authenticated heade… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Mike Copley
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Stephen Farrell
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Ilari Liusvaara
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Mill
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Martin Thomson
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jeff Burdges
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum