Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Bryan A Ford <brynosaurus@gmail.com> Mon, 30 November 2015 10:16 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 3289F1A8A3F for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 02:16:25 -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 gLdn1DBXibbV for <tls@ietfa.amsl.com>; Mon, 30 Nov 2015 02:16:20 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 723E91A8A3E for <tls@ietf.org>; Mon, 30 Nov 2015 02:16:19 -0800 (PST)
Received: by wmww144 with SMTP id w144so122387342wmw.1 for <tls@ietf.org>; Mon, 30 Nov 2015 02:16:18 -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=5iQChHL6G93NIbu9qqnhkf8PMwNUfyNL7tZZBoeKiWQ=; b=zkjOsq8fueyeq8aDnLfa4CaMNB6Yc3n+RrSuTFSXpivtNxVNo2VK5i8Kgcab/blntF o57pwNnLDBQfQ5fP9w7tVRAC0ozrxxIAC2qHrU1gPv8F41HT3U6AWA/wh+n9OrIqNpUb wjyWZCDdn+hdfSBB5OpjVm377jv07cBhF4a0K5KtpfSD8smsPQqlkvoB8+pnNuv874MO S6S7MjQJVZ6wndpIMdb8D5CYJC4clk6ec7eTAjlA1TNA9kqo3GG7loyht/HMN/ZShqP3 pBWLF/wma1tAn2r72iiJiBeUKAR7qiVS4tYGwUvXwxGRft84bwrJ6S8UYOTyPdJT30gx VJPw==
X-Received: by 10.28.50.70 with SMTP id y67mr27871229wmy.91.1448878578028; Mon, 30 Nov 2015 02:16:18 -0800 (PST)
Received: from tsf-476-wpa-0-088.epfl.ch (tsf-476-wpa-0-088.epfl.ch. [128.179.176.88]) by smtp.gmail.com with ESMTPSA id i84sm20739946wmc.20.2015.11.30.02.16.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 02:16:16 -0800 (PST)
To: Bill Cox <waywardgeek@google.com>, "tls@ietf.org" <tls@ietf.org>
References: <56586A2F.1070703@gmail.com> <565882FE.80205@streamsec.se> <565AC9D1.700@gmail.com> <565AE180.70101@streamsec.se> <565AEB5A.9000503@gmail.com> <CAH9QtQEK0NjPMD7cV=xEGjRc5UbKGu2FeTHQXF7kxFg+pTLW3A@mail.gmail.com>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <565C21EF.1060600@gmail.com>
Date: Mon, 30 Nov 2015 11:16:15 +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: <CAH9QtQEK0NjPMD7cV=xEGjRc5UbKGu2FeTHQXF7kxFg+pTLW3A@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020302030704060605020907"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vrY2wMmSJZJgFL3laV5AXKfI4C8>
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 10:16:25 -0000
Thanks Bill for the feedback. On 11/29/15 6:11 PM, Bill Cox wrote: > Thanks for the detailed description of why we might want to obfuscate > TLS record lengths. From a security point of view, the only potential > attack vector this might create is that the attacker will know in many > cases the plain text of the first 5 bytes. A weakness in the stream > cipher might be more easily exploited in this case. IIUC, we feel > pretty good about the latest AEAD ciphers, and guessing the clear text > of many bytes in the record already is not too hard. Is that right? > So, from my fairly uninformed point of view, this seems like a > reasonable upgrade. Just a nitpicky semantic correction: my proposal doesn't "create" the attack vector you describe (that the attacker will know the plaintext of the 5-byte header). That weakness is already there in TLS 1.3 as currently specified, because the TLS header is unencrypted so the attacker will *definitely* know the 5-byte header. :) This is merely an existing weakness that is not fixed by my proposal. > I have one concern. These same boxes that hide record lengths by > merging and breaking up packets arbitrarily likely would deliver the > packets not well aligned to record boundaries. Is this already the > case? It's already the case that middleboxes of various kinds re-segment (merge and break up along different boundaries) TCP streams for various reasons, often as an unintentional side-effect of interposing on the stream by "accepting" the TCP connection (pretending to be an endpoint) on one of the middlebox's interfaces and opening a new outgoing connection on the other interface, and just forwarding the traffic between them. In fact, Performance Enhancing Proxies (PEPs) are one class of middlebox that often do this intentionally, so they can get better control over and fiddle with the way congestion control works over "troublesome" types of links like high-bandwidth-delay-product (e.g., satellite) links. > If these boxes currently inspect packets when breaking them up to > split packets along record boundaries, encrypting the lengths will > defeat this efficiency hack. We might cause an increase in network > latency in this case. Do any of the routers out there currently use the > record length field when splitting up packets? If I understand your question correctly, you're asking if encrypting TLS record lengths might break middleboxes that currently want to track TLS records for some reason, e.g., perhaps to re-segment the TCP stream to correspond to TLS records (which might "fix" or "revert" the effect of another middlebox in the path that re-segments TCP in a TLS-oblivious fashion). I don't know of any middleboxes that do precisely this, but it's not inconceivable that they could exist. More generally, since basically all manner of evil/broken middleboxes do exist, it's entirely possible that most any change to TLS's wire encoding *could* disagree with some middleboxes. That's not specific to the change I'm proposing; any wire-visible change could trigger unknown middlebox badness. The only solution to this I'm aware of is empirical: try the change, deploy it experimentally at first, and see what the pain level is, i.e., see if we find any middleboxes that complain and if so how prevalent they are. But since TLS 1.3 is already changing a lot of other prominently wire-visible stuff with respect to prior versions of TLS that might equally well break middleboxes, it's not clear that my proposed change in particular is more likely to cause pain than any of the other changes already made, and in general I don't think we should let a few broken/evil middleboxes prevent meaningful evolution of the TLS protocol. Cheers Bryan > > Bill
- [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