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

Nikos Mavrogiannopoulos <> Sun, 29 November 2015 20:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E9A81B331F for <>; Sun, 29 Nov 2015 12:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j1l_4YvhC5Bf for <>; Sun, 29 Nov 2015 12:00:42 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32B561B3323 for <>; Sun, 29 Nov 2015 12:00:39 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id tATK0cCb015089; Sun, 29 Nov 2015 15:00:38 -0500
Date: Sun, 29 Nov 2015 15:00:38 -0500
From: Nikos Mavrogiannopoulos <>
To: Bryan A Ford <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [,]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922)
Thread-Topic: Encrypting record headers: practical for TLS 1.3 after all?
Thread-Index: r+tS4hiLCGV+LeIEk+XqLpQ52xLw0g==
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: Sun, 29 Nov 2015 20:00:43 -0000

----- Original Message -----
> The idea of encrypting TLS record headers has come up before, the most
> important purpose being to hide record lengths and boundaries and make
> fingerprinting and traffic analysis harder.  I had convinced myself that
> goal this would be "too hard" to accomplish in TLS 1.3, but after
> further thought I'm not so sure.  So I would like to request comment on
> one approach that strikes me as a practical and requires only a rather
> minor change to the current spec.

I believe your proposal is a nice example of putting the cart before the
horse. Before proposing something it should be clear what do you want to
protect from, what is the threat? Here you imply that the revealing the length
is somehow a weakness. However, TLS isn't supposed to hide lengths and never
did [0]. So will hiding the length _field_ of such a protocol, will really
protect against attacks taking advantage of packet lengths? If you see 
the previous work of analyzing TLS packet lengths they don't even need to 
read that length field, they just use the packet length on the wire.
There is already a solution for protecting packet lengths, and that's
called padding [1].


[0]. the cbc ciphersuite approach was a half baked approach which never worked.