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

Yoav Nir <> Wed, 02 December 2015 06:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0414E1B3391 for <>; Tue, 1 Dec 2015 22:53:50 -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 luHebpkfrniw for <>; Tue, 1 Dec 2015 22:53:48 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 061A71B338E for <>; Tue, 1 Dec 2015 22:53:48 -0800 (PST)
Received: by wmuu63 with SMTP id u63so201859004wmu.0 for <>; Tue, 01 Dec 2015 22:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RjL1HsjjRoMD76P4XBRtVomUce2IUk2K5u1dnoOfk4Y=; b=oZNby/AzgQk7WWdKTjSWkU2BfzBnYhzEhZFreXcD+ZpA16m5eqU6pI1ZCiBqOkMDoA g8lEE8588Srj+OMdcG5dgx0FGWpqWNlhNfjlC+u0f7HCQm3uvuzwwLaCOfAc30jiMFr8 zuhV+s9vYq5vXKMhyFC2ffgSvy2nlyczwlxgKei1ATxDTGHq5xSJDJsXRvPToXn4cDDy Qesth8OjhbyDoQVPEYv59Uo62Sx88sE/cKUuXmN8nZeDnJVMwq2K+7c9xc2WeB8z1zmz CynsXKY6nExUzNyVj5xVJN2RjiU0hx+0vYFqYl6xU8OkB45cuFDmoPI5vYEoo6XXkIB9 XIrQ==
X-Received: by with SMTP id a8mr3459434wmc.67.1449039226677; Tue, 01 Dec 2015 22:53:46 -0800 (PST)
Received: from ([]) by with ESMTPSA id v196sm1742803wmv.10.2015. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Dec 2015 22:53:45 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 02 Dec 2015 08:52:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Bryan A Ford <>
X-Mailer: Apple Mail (2.3096.5)
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: Wed, 02 Dec 2015 06:53:50 -0000

> On 1 Dec 2015, at 4:55 PM, Bryan A Ford <> wrote:
> 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?

Convenience has nothing to do with it. The next version of every firewall out there is going to support TLS 1.3. If TLS 1.3 means that the middlebox cannot parse the record lengths, then the next version of the middlebox will give the administrator the option of blocking TLS 1.3 or disabling the processing that requires following record lengths.  The issue is with all older version middleboxes that are out there. They don’t get updated nearly as often as we vendors would like. 

And the IETF is in the business of developing protocols that work and can be deployed. For counter-examples look at SCTP. It is not deployed because middleboxes (mostly NAT devices in this case) didn’t know what to do with it. It’s fairly simple to NAT SCTP, but the old middleboxes didn’t know how. Newer middleboxes still mostly don’t know how to NAT SCTP. Why? Because nobody’s using SCTP, so why bother? There are a dozen other features that customers actually want that need to be developed.

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

That is not what a downgrade dance is. The normal way of version negotiation goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) OK, I choose 1.2.

By the end of the handshake both of the above messages enter the calculation of the Finished message so it’s fine.

A downgrade dance goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) RST
Client: (old server that didn’t implement version negotiation right. Sigh) I support TLS 1.1, 1.2.
Server: OK, I choose 1.2.

In this case only the last two messages get into the Finished message. As a result, an attacker (whether on-path or not) can easily induce the downgrade dance by sending a RST, but it cannot induce version negotiation down to 1.2. Browsers are just now getting rid of the downgrade dance they had for 1.2. It would be a shame to have to re-introduce it.