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

Yoav Nir <ynir.ietf@gmail.com> Tue, 01 December 2015 09:12 UTC

Return-Path: <ynir.ietf@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 97A2C1B3992 for <tls@ietfa.amsl.com>; Tue, 1 Dec 2015 01:12:53 -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 3ju4vy9fTFj5 for <tls@ietfa.amsl.com>; Tue, 1 Dec 2015 01:12:51 -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 55B3C1B3994 for <tls@ietf.org>; Tue, 1 Dec 2015 01:12:51 -0800 (PST)
Received: by wmww144 with SMTP id w144so4011560wmw.0 for <tls@ietf.org>; Tue, 01 Dec 2015 01:12:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kAJwnn2I1s7E0ZvHzcO5RY4L7XpFTwDgpi3jKDEHHyw=; b=mWA1Tw3HXNSFC7aCFgFIeZqcyak/FfZyA91BioG26XBjbhm95clE+V15214V0STIcF y/HskqhrA/qHKCJETgnVDmLlUMXL4dDp8DQT5sL6ZqCHyLRz6UxeJov9GJaFB03HSIO2 FUqhU7cGFffSPMtOLXKp1L+Q+F7E9rLW2BTlDiGqQIoTh3vQPHiIFjP+bxtR2Fm1N4dN Lr2tFfnUrYZ8opOWqB5A8BSwDhwWb8G2Rmoj3p72D+5k6EF8KSJIyFVOZxBWZyhirezs saewTSw+qvEpE/AHzmNr5RIWOvu3PhAdm977U7h8rmKJ+CK9W8+iGCRZ2Yqkysnbraf3 cqOw==
X-Received: by 10.194.87.201 with SMTP id ba9mr43000126wjb.125.1448961169856; Tue, 01 Dec 2015 01:12:49 -0800 (PST)
Received: from [172.24.248.183] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id n7sm25036897wmf.21.2015.12.01.01.12.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 01:12:48 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAFggDF03fzyAw95Ka8NHtBGEcebAe3RCt5pRd3r8_nhBbR7oNw@mail.gmail.com>
Date: Tue, 01 Dec 2015 11:12:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <CAFggDF03fzyAw95Ka8NHtBGEcebAe3RCt5pRd3r8_nhBbR7oNw@mail.gmail.com>
To: Jacob Appelbaum <jacob@appelbaum.net>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/FLnnPuExUoLVZwhPSzYCSG6jkjQ>
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 09:12:53 -0000

> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
> 
> On 12/1/15, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote:
>> 
>>> Bryan A Ford <brynosaurus@gmail.com> writes:
>>> 
>>>> It would work just as well and in exactly the same way if the AEAD is
>>>> replaced with the traditional Encrypt-then-MAC construction, for
>>>> example.
>>> 
>>> No it wouldn't, unless the encrypt part is a stream cipher.  You're still
>>> locked into using an AEAD stream cipher or the equivalent of an AEAD
>>> stream
>>> cipher built with encrypt+MAC.  It won't work with, for example, the OCB
>>> AEAD
>>> mode, or CBC + MAC.
>> 
>> I think we should focus on what would get TLS 1.3 to be adopted:
>> 
>>    * Reasonably implementable in libraries that support older
>>      versions alongside TLS 1.3.
>> 
> 
> That doesn't change with Bryan's suggestion, I think.
> 
>>    * Interoperable in the field with various capital-intensive
>>      middle boxen.
> 
> Which would those be? And what is the definition of capital-intensive
> for those watching on the sidelines?

Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on protocols to make sure that the stuff going over TCP port 443 is really HTTPS rather than an attempt at tunneling.  There are some attacks such the the code that protects against them needs to follow TLS record sizes. For the most part these are not-so-interesting attacks, causing certain versions of certain browsers to hang, and they are expensive for the firewall to protect against, so for the most part these protections are turned off. But it’s not everywhere.

If enough middleboxes block TLS 1.3, the browsers will implement a downgrade dance. If they do that, attackers will be able to exploit the downgrade dance. I don’t think the net effect is better security. We’d be far better off writing a separate document on how to use the padding feature that is already in 1.3 to mitigate traffic analysis without actually flooding your Internet connection. Splitting records and padding a few can be more effective than masking the length bits.

Yoav