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

Bryan A Ford <> Sun, 29 November 2015 12:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E7D61ACC91 for <>; Sun, 29 Nov 2015 04:11:02 -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 l70hh9MrXvMZ for <>; Sun, 29 Nov 2015 04:11:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 802F01ACC92 for <>; Sun, 29 Nov 2015 04:11:00 -0800 (PST)
Received: by wmvv187 with SMTP id v187so120821564wmv.1 for <>; Sun, 29 Nov 2015 04:10:59 -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=1ZzVCvbYNMY+5gfpRX5xAERzy2T4jqjBuiWO+LaBY80=; b=BRhIsF8QmLgHy+kJv5B6y/9uZeRV7nBRK3Leh8cjaP1LKeaJzq6tONpUA8x2adM0gt VeII0Yg93KaDaxKnGMly7w/3p/+LVQy3A2dxpwvUN6TIQrd7gSvRblu4CBgUDxHcFDv7 WVRTedzjIk/JGpg22r99QPifbsQNwG/CfXo5TMY+7/u4LSP5FGUrpXkvjJ1dgGEFeqmL tDj2ZUzAQtRnahypsb/7N2DODWztiwUkSYMiMf/Lru1F1Oc6F+MVdQuwvHNvMRYrgoPz E5HXUZfZPL045CeMHhmS5OLwexnQtdELMkDEKF9185QJ0h5Nw9LLtU0UPT6ncVwKd28a 12ZQ==
X-Received: by with SMTP id tr6mr77080695wjc.21.1448799059024; Sun, 29 Nov 2015 04:10:59 -0800 (PST)
Received: from ( []) by with ESMTPSA id q6sm41733118wjx.28.2015. for <> (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 04:10:57 -0800 (PST)
References: <> <> <> <>
From: Bryan A Ford <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Sun, 29 Nov 2015 13:11:06 +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="------------ms090606060509060600030509"
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 12:11:02 -0000

On 11/29/15 12:29 PM, Henrick Hellström wrote:
> On 2015-11-29 10:48, Bryan A Ford wrote:
>> In short, leaving TLS headers in cleartext basically hands any
>> eavesdropper a huge information side-channel unnecessarily and precludes
>> anyone*but*  the TLS implementation itself from adding any traffic
>> analysis protection into the system.  Encrypting TLS headers appears to
>> cost practically nothing (at least if done as I've proposed), and it
>> allows traffic analysis protection (whether weak or strong, intentional
>> or unintentional) to be introduced at multiple points: e.g., by TLS
>> itself, or by the TCP stack, or by middleboxes.
> Thank you for the explanation. A few points:
> The only way to completely thwart traffic analysis, is to always send
> data with the exact same amount-frequency pattern. The middleboxes you
> describe will *not* be able to achieve this, unless the TLS sender is
> adapted for such processing anyway.

Very true.  But perfect traffic analysis protection isn't the only goal
of interest, and is usually impractical anyway.  A less ambitious but
still worthwhile goal is simply to make sure that in
imperfectly-protected connections, transmission bursts leak as little of
their internal structure as possible even though the timing and burst of
the (whole) burst will still inevitably risk leaking something.  Even
when it's impractical to leak nothing, it's still worthwhile to leak less.

A fairly important common-case example of this, I think, is Web page
loads in which the client submits a bunch of requests in parallel over
the same connection.  This was never widely enabled in HTTP/1.1 due to
compatibility concerns but will probably become the norm quickly with
HTTP/2.0.  A TLS implementation designed without much concern for
traffic analysis will probably send those multiple small
requests/replies in separate TLS records, giving eavesdroppers a nice
fine-grained fingerprint of what all is in that transmission burst.  If
TLS 1.3 hides its headers, then either the TLS implementation, the TCP
stack, or a middlebox could readily scrub that internal structure and at
least make life harder for the attacker (e.g., reduce the bandwidth of
the side-channel).  That seems worthwhile to me if it doesn't cost much.