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

Bryan A Ford <> Tue, 01 December 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BA79F1A92F6 for <>; Tue, 1 Dec 2015 06:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LuU5En3strJo for <>; Tue, 1 Dec 2015 06:55:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B7D71A92F0 for <>; Tue, 1 Dec 2015 06:55:26 -0800 (PST)
Received: by wmec201 with SMTP id c201so17099179wme.1 for <>; Tue, 01 Dec 2015 06:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=kFE6yA+l0EqJCuJ7rFY1W7lmVLCjAOrc9ZahTenpNO0=; b=NDG/BtcqOJcknQbEWnzDIiTCqP8gPlvnl10fWy+bDeInl28wG/cNH24FhOJ4m7Vhi1 H+EjvpAX3EgJiodsYnzc9nXAU4oYRK2rGeQkPADj4s6tUd93tukCnraWaPnKnmwDpOpk dXmHYCLzk8GziqhZnAMwyMX3Jm6FrPhMgXlPoa1nh6doINHmRR1Fyol9/ay6ZbbnlRyF yR0SLBdnr+RP7esrBiu9oPgYlov+5YBh9St+zbthPhZouGxXkBeyVCOJIJ8OEhX2AgLS opf3HZ/JxGHW77R+cCjZQ6UP36+e3mQ+6FWl41t/is6IjRTAI/tkNDxaoazhTWWJ88wN G3sw==
X-Received: by with SMTP id v131mr37709513wma.63.1448981724644; Tue, 01 Dec 2015 06:55:24 -0800 (PST)
Received: from ( []) by with ESMTPSA id m16sm26682034wmb.13.2015. for <> (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Dec 2015 06:55:23 -0800 (PST)
References: <> <> <> <> <> <> <> <> <>
From: Bryan A Ford <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 01 Dec 2015 15:55:21 +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: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020600020804000806060701"
Archived-At: <>
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Dec 2015 14:55:34 -0000

On 12/1/15 10:12 AM, Yoav Nir wrote:
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <> wrote:
>> On 12/1/15, Viktor Dukhovni <> wrote:
>>>    * 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.

Certainly there are middleboxes that try to use traffic analysis to
detect attempts at tunneling - but the fact that the traffic is HTTPS
doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation
does exactly that (and is sometimes used for exactly that purpose).

Regardless, does the IETF really want to be in the business of making
sure that protocols like TLS are designed to avoid making life
inconvenient for developers of Great Firewalls of whatever type?

> 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.

Browsers have to implement a downgrade dance anyway to be able to talk
with web servers that don't support TLS 1.3.  TLS 1.3 already changes
plenty of things that middleboxes "might" not like; absent concrete
evidence of major incompatibilities specifically caused by the proposed
change, I don't see why we should avoid changing one more bit of the
protocol that middlebrowsers "might" not like.