Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Bryan A Ford <brynosaurus@gmail.com> Sun, 29 November 2015 09: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 9074B1B3007 for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 01:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 KAWUIq3RCT6S for <tls@ietfa.amsl.com>; Sun, 29 Nov 2015 01:16:35 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 02FB61B3006 for <tls@ietf.org>; Sun, 29 Nov 2015 01:16:35 -0800 (PST)
Received: by wmvv187 with SMTP id v187so117835025wmv.1 for <tls@ietf.org>; Sun, 29 Nov 2015 01:16:33 -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=SC2s056CfGRHTwauvmrSfOt45JrSMsLeU9w8BurSF60=; b=R1pc2i1ewo+YTqGuFgSo+9m0FyE5uVBc9rEvEmM09sYxr74HTYswQJVVf7VsuahfoS cVrCHEKDTz5qE2dDVlLoQNOQddaBKoKbN9OrUxph32Z+JpUavRw8HlmJyxcQh2JKfdH+ xpAiBrzGIZPhe6lfNwX9x8pnRvvfiAHq5vg2yMzTPJ6hJnOBXdktnCEQV3dNKgecqEpL xI1yFoLmOYFSZOPZBf+/bgkVPm7dA+99q+m29Aleem/ZeD6bSrC6DfBStXQoCQmfnlcN KOt9HCtRaxlJE4hVYZb0cuEP7QntW52htlFLcyvLkFIiUcM+qvKXImcmzAV9634Y72C3 ko4g==
X-Received: by 10.194.186.170 with SMTP id fl10mr63632150wjc.91.1448788593598; Sun, 29 Nov 2015 01:16:33 -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 c4sm41202563wjs.36.2015.11.29.01.16.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 01:16:31 -0800 (PST)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz>
From: Bryan A Ford <brynosaurus@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <565AC278.2010904@gmail.com>
Date: Sun, 29 Nov 2015 10:16:40 +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: <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070308020507070705010402"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PPyeZ_1Fbr53X76DJ3YyKghD_CI>
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:16:37 -0000
Hi Peter, On 11/28/15 12:15 PM, Peter Gutmann wrote: > Bryan A Ford <brynosaurus@gmail.com> writes: > SSL/TLS have used unencrypted lengths for twenty years without there being any > (known) attack or weakness based on this. Leaving all headers in the clear (and in particular record lengths) is a huge side-channel, and historical experience is that attackers are getting better and better at exploiting side-channels in surprising ways. The CRIME attack, for example, applied to a close relative of TLS (namely SPDY), and exploited the attacker's ability to learn precise information about (compressed in this case) record lengths. I'm not saying that hiding TLS/SPDY record lengths in particular would necessarily address the CRIME attack (there were many factors involved and a combination of weaknesses), but it is certainly an attack in which the attacker's ability to see fine-grained length information was a factor. The general lesson is simply that lengths do represent sometimes-exploitable side-channels. > OTOH SSH has used encrypted lengths > for nearly the same period, and there have been several attacks/weaknesses > based on that. Security-wise, it has the opposite effect of the one intended, > it makes the protocol weaker, not stronger. You're conflating the goal (hiding TLS headers) with one particular old, broken approach to achieving that goal (namely SSH's). I am not proposing to hide TLS headers in the same way SSH did, and just because one historical approach to hiding headers was broken doesn't mean that the goal itself is a bad idea, or that all possible ways to achieve that goal are broken, or that my proposal in particular is broken. Feel free to attack my proposal but then please attack *my* proposal, not the old broken SSH approach. I already addressed one specific weakness the SSH approach had and explained why that's not an issue in my proposal. You allude to "several attacks/weaknesses" SSH had: if there were several, can you summarize or point me to information about the others? And can you say whether and in what way any of those past weaknesses in SSH might conceivably apply to my proposed approach? I claim you won't be able to (but would be happy to be shown wrong), because there appears to be a rather trivial "security proof" that my proposed hiding approach can't possibly create any new security weaknesses that weren't already in TLS 1.3 as currently specified. I already outlined that reasoning in my proposal but will expand on it a bit more below. > My real issue with it though is that, as you've pointed out, it makes it > impossible to create an efficient streaming implementation. With TLS you read > the length at the start, stream the rest into the target memory location, and > decrypt in place. With SSH you have to read a single block, decrypt it, make > sure you're not providing an oracle for the attacker, copy what's left around, > read more encrypted data onto the end, decrypt the remainder, ugh. How exactly does my proposal make it "impossible to create an efficient streaming implementation"? Again, it sounds like you're attacking SSH's broken approach while ignoring my proposal itself. With my proposal you can still perform exactly the same optimization just as before: 1. Read the 5-byte TLS header at the start, and decrypt it by XORing with the output of the stream cipher as my proposal specifies, so you now have the length. 2. Stream the rest into the target memory location, and AEAD-decrypt in place. I don't see how my proposal in any way makes life more difficult for such streaming optimizations, because my proposal keeps encryption/decryption of TLS headers separate from encryption/decryption of the body. What *might* make this optimization a bit more difficult is the MAC that the AEAD wants to attach to each ciphertext, but if that's a problem it's caused by TLS's use of AEAD and has nothing to do with my proposal. (That problem can in principle be worked around if the AEAD cipher implementation has a simple "scatter/gather" capability so it can put the MAC elsewhere, but that's a completely separate and orthogonal topic.) Now, returning to your concern about TLS header hiding creating security weaknesses: my claim is that all that my proposal introduces is a change of encoding of the 5-byte TLS header, which cannot possibly introduce any new security weaknesses because it is not affecting in any way the actual information content transmitted or received in the protocol or the way it is processed outside of that header encoding change. Consider this example: Suppose we decided we wanted the 2-byte length field in the TLS header to be transmitted in little-endian rather than big-endian. A useless change, yes, but could it create a new security vulnerability that TLS 1.3 doesn't already have as specified? Obviously not; this would yield a perfectly (and provably) equivalent protocol. Similarly, what if we decided for whatever reason it would be nice to XOR the 5-byte length field with the constant five-byte sequence [0x55,0x55,0x55,0x55,0x55]? Could that create a new security vulnerability? Again, obviously not. What if we decided that the TLS headers of odd-numbered records should be XORed with [0x55,0x55,0x55,0x55,0x55], and the even-numbered records should be XORed with [0xaa,0xaa,0xaa,0xaa,0xaa]. Could that create a new security vulnerability? No, it's still just an encoding change - just one that happens to depend dynamically on record number. What if we decided that the TLS headers should be XORed with an MD5 hash of the record number? Again, useless from a security perspective, but not harmful either: it's still just changing the TLS header encoding without changing anything else about how the protocol works - and in particular doesn't change anything about how the record is AEAD-protected or how the protocol behaves if an attacker flips any bits. What if we decided that the TLS headers should be XORed with an HMAC-SHA256 of the record number, keyed with a shared secret used only for TLS header hiding? This is now (finally) potentially useful from a security perspective, and is basically isomorphic to my proposal - but even if the attacker could break HMAC-SHA256 tomorrow or could learn the shared secret used for TLS header protection, we would just be back to the same security level as TLS's current cleartext-header design achieves; we would still not be introducing any new security weaknesses that TLS 1.3 doesn't already have. Again, if you believe my reasoning is in any way flawed here, please point out how you think my proposal (*not* the old SSH approach) could conceivably introduce any new security weaknesses that TLS 1.3 doesn't already have. Thanks 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