Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Bryan A Ford <brynosaurus@gmail.com> Sun, 29 November 2015 09:47 UTC
Return-Path: <brynosaurus@gmail.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 C98391B30D7 for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 01:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 PLRqn67-_n-4 for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 01:47:55 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 721291B30D6 for <tls@ietf.org>; Sun, 29 Nov 2015 01:47:55 -0800 (PST)
Received: by wmww144 with SMTP id w144so102691501wmw.0 for <tls@ietf.org>; Sun, 29 Nov 2015 01:47:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=oW0dTxnEGazQEw1Fo59HB1H7kBGw+8qJvbiJgmMgzmU=; b=EX3z5sV7vkWYNlSJtlGAf6X6YV/eHvTist2iIEricrrpUiI1L5SvYJRcgfAw5Mqv0V fz0zHgXUJwufnzgjmJKwyW4LmyYk3+gsanWWP9AyZLpsqqN0nP6kZKSW1C2syOI/YIUa jlllOcTU2lNMEEe1oLWSN2xDnHqgRbcFcQN0wteDODAcR5zFhM+Kl96F78mXXNIxc1cF VSXasP4UOMrf30vVrRlaMuWcubMPhlKhRtFitbf3WuQ7BYoPYnK58UcCuU1vvJVKqEg9 AmKbXY/Z9XasqQKqbezmZcRG9nOC5Jb9nCuodlk77kh1Fud/GsbRMfBnCdLHLO0VhoDF tuAw==
X-Received: by 10.28.103.84 with SMTP id b81mr20013996wmc.39.1448790474086; Sun, 29 Nov 2015 01:47:54 -0800 (PST)
Received: from proz.dclient.lsne.ch (85-218-12-53.dclient.lsne.ch. [85.218.12.53]) by smtp.gmail.com with ESMTPSA id bk2sm41514310wjc.3.2015.11.29.01.47.52 for <tls@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 01:47:52 -0800 (PST)
To: tls@ietf.org
References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <565AC9D1.700@gmail.com>
Date: Sun, 29 Nov 2015 10:48:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <565882FE.80205@streamsec.se>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040705020904070503050101"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TQ-_8eeAkFp-3VhF7CrxHVqjD2k>
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: Sun, 29 Nov 2015 09:47:58 -0000
On 11/27/15 5:21 PM, Henrick Hellström wrote: > On 2015-11-27 15:35, Bryan A Ford wrote: >> The idea of encrypting TLS record headers has come up before, the most >> important purpose being to hide record lengths and boundaries and make >> fingerprinting and traffic analysis harder. > > How, exactly, would this be significantly harder? The adversary will > still be able to tell when, and how much, TCP/IP data is sent between > the peers. If there happens to be a revealing TLS record boundary in the > middle of a TCP/IP packet, it would seem to me there is an > implementation problem rather than a problem with the abstract protocol. There are a variety of reasons TLS segment boundaries can and often do become desynchronized from TLS record boundaries, such as: (a) if the TLS implementation happens to encrypt several consecutive records in a buffer and sends them with one write() call for efficiency. (b) if the kernel TCP stack's send buffer is already non-empty on write (e.g., held back to to congestion or flow control) and the TCP stack decides simply to append the newly-written data to the already buffered data, the boundary between those wrotes need not appear as a TCP segment boundary. (c) quite a few middleboxes can and do silently re-segment TCP streams obliviously to the content of that stream. In particular this tends to happen as an incidental side-effect whenever the middlebox interposes on the TCP stream by "terminating" the TCP connection and transparently forwarding the content to/from a second TCP connection. Now, this doesn't mean that "incidental" desynchronization of TCP segment boundaries from TLS record boundaries will by itself add any kind of robust protection against traffic analysis. To achieve that, we would want to ensure that a burst of (say) multiple HTTP requests and their responses over the TLS connection get merged together and then transmitted as a uniform-length series of blobs. A sufficiently careful TLS implementation could potentially achieve this, but with TLS headers sent in cleartext, the TLS implementation is the *only* entity in the system that can provide any kind of traffic analysis protection. With TLS headers encrypted, it becomes feasible for some (weak or strong) traffic analysis protection to be introduced at multiple points: 1. The TLS implementation can do it, either way. 2. Even if the TLS implementation doesn't try to provide any traffic analysis protection, the kernel's TCP stack could provide some protection (either intentionally or unintentionally) simply by merging together consecutive writes as discussed above, so that transmissions are usually just bursts of MTU-sized TCP segments even if they hold many varying-size TLS records. 3. Finally, middleboxes can (again either intentionally or unintentionally) add traffic analysis protection by re-segmenting TCP traffic. Corporate network operators often already see NATs as a security advantage because they obfuscate the source IP addresses of connections coming from the private network. If TLS 1.3 encrypts its record headers, then network operators and the middleboxes they deploy will similarly be able to add traffic analysis protection "in the middle" by re-segmenting TCP streams (which many of these middleboxes may already be doing anyway), and whatever protection this provides will apply to automatically to *all* TLS 1.3 traffic crossing that middlebox, even if few or none of the actual TLS 1.3 endpoint implementations know or care about traffic analysis protection. 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. Cheers Bryan
- [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