Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Bryan A Ford <> Thu, 03 December 2015 08:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F8F81B32CA for <>; Thu, 3 Dec 2015 00:50:13 -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 jWGMmgvXJdWL for <>; Thu, 3 Dec 2015 00:50:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF8291A1BDD for <>; Thu, 3 Dec 2015 00:50:10 -0800 (PST)
Received: by wmuu63 with SMTP id u63so11444058wmu.0 for <>; Thu, 03 Dec 2015 00:50:09 -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=xMGInjA5CwnGqBrH+EJdrzPP8qDZSW3Na0krpczpaDU=; b=Hi325vi2YNZZnrLjJnLFA6pa9z7gYTYxIDQNCLQnYBI5V3RzTStlZILcWPZRzg8yea BSVuHifNuLAj4d47pEOpFbtJT2hPDFxaCQG1U+WdSbn18mBty4dfxsSDJlWw3J7Mob1k Ln566XVTlZVJ9r5IqX5O8GsGCZyiUORmFKFCjAfn1MHTwsHuWJaimRW8ps62BiIdFLnL pHNCRGYfstm035A0KmUViZhHLDOQbye4d5Jh4xkKYokhzmrN/ZYsANtMJnqJsoMIn16Z 0orGTCq+j6ojGsYIMboM9UVarFO+TfFJHrN8jWPwVyzweYuC0GBCtoxowcuTRbU54o74 HdCQ==
X-Received: by with SMTP id yt1mr10127970wjc.89.1449132609270; Thu, 03 Dec 2015 00:50:09 -0800 (PST)
Received: from ( []) by with ESMTPSA id jt9sm6535380wjc.24.2015. for <> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 00:50:07 -0800 (PST)
References: <> <> <> <> <> <> <> <> <>
From: Bryan A Ford <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 03 Dec 2015 09:50:11 +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="------------ms070900040107050009020609"
Archived-At: <>
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: 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: Thu, 03 Dec 2015 08:50:13 -0000

On 12/2/15 4:45 PM, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <> wrote:
>> On 12/2/15, Eric Rescorla <> wrote:
>>> It's not really clear to me what the anti-traffic-analysis benefit of your
>>> proposal
>>> is over and above just padding everything to a fixed size. That's certainly
>>> far
>>> easier for the implementation to do, especially in typical stacks where the
>>> application just calls SSL_Write (or whatever) and so there's no obvious
>>> API point to provide the "next length", so as a practical matter the stack
>>> will very often if not always be in "last block" mode.
>> I think that it eliminates all static distinguisher in the protocol
>> for all data covered by the encryption. That is a fantastically
>> wonderful benefit.
> What's a "static distinguisher"? Padding solves this problem as well,
> but it also solves problems resulting from TCP segmentation down the
> stack, which header encryption doesn't. What does header encryption
> offer that padding does not?

Once again (for the n'th time in this thread):  Padding is great and we
should encourage implementations to do it, but it may be impractical to
mandate (a) that *every* TLS 1.3 implementation use padding all the
time, and (b) that *every* implementation that does use padding uses the
*same* padded record size as every other TLS implementation.

If TLS 1.3 did mandate that all implementations always pad to the same
standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM!
:) ), then it might be arguably the case that encrypting headers
wouldn't add any further benefit.

But short of that, encrypting TLS headers makes it strictly harder for a
passive adversary - or an active adversary who can only inject but not
block traffic - to distinguish between padded or unpadded TLS 1.3
streams, or to distinguish between TLS 1.3 streams padded to different
block sizes.

In particular, with encrypted records, we get a guarantee that nothing
in the transmitted TCP stream content itself leaks information about the
internal pattern of records, even if it's un-padded or differently
padded from other streams.  The attacker has to use other side-channels
to perform such distinguishing attacks, and other side-channels are
often lower-bandwidth (e.g., the total length of whole streams or bursts
rather than individual records), and/or more noisy (e.g., the lengths
and timings of TCP segments, which may get retimed and/or resegmented by
all sorts of activities both at the endpoints and in the network).


> Sincerely,
> Watson