Re: [TLS] Encryption of TLS 1.3 content type

Brian Sniffen <> Mon, 28 July 2014 15:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3C1F1B28A0 for <>; Mon, 28 Jul 2014 08:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tpm70cfKLdiU for <>; Mon, 28 Jul 2014 08:35:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 96F481B289D for <>; Mon, 28 Jul 2014 08:35:06 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id C710C4742C; Mon, 28 Jul 2014 15:35:05 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 9EC404742E; Mon, 28 Jul 2014 15:35:05 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 8BB952026; Mon, 28 Jul 2014 15:35:05 +0000 (GMT)
Received: from Tereva.local ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 28 Jul 2014 11:35:04 -0400
From: Brian Sniffen <>
To: Yoav Nir <>, Nikos Mavrogiannopoulos <>
In-Reply-To: <>
References: <> <> <> <> <>
User-Agent: Notmuch/0.18.1 ( Emacs/24.3.1 (x86_64-apple-darwin12.4.0)
Date: Mon, 28 Jul 2014 11:35:04 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Cc: "<>" <>
Subject: Re: [TLS] Encryption of TLS 1.3 content type
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: Mon, 28 Jul 2014 15:35:10 -0000

Yoav Nir <> writes:

> On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos <> wrote:
>> Are there any pointers to these attacks? Will these attacks be countered
>> with such a change? I believe not as alert messages consist of only two
>> bytes and will be distinct from any other higher protocol messages
>> transferred by the TLS record protocol. Unless TLS 1.3 intended to
>> include a length hiding mechanism I see this change as unnecessary and I
>> agree with Watson on that.
> While no definite decisions were made, there was a positive response
> to the idea of allowing arbitrary length padding to the plaintext in
> all encrypted records, which can be used to hide alert messages.

It's not clear to me that it can be used to hide alert messages, or the
structure of the interaction at that level at all.  Can you show me a
model of a TLS 1.3 client state machine and a TLS 1.3 server state
machine such that they both do padding, send messages on a clock, and
otherwise take best-understood precautions against passive
analysis---and then don't leak when there are alert messages?

I expect closing a connection leaks quite a bit about what came just
before the close.  I expect timing leaks quite a bit---and an adversary
who can be slightly active (e.g., opening his own connection to the
server) can learn about timing differences between alerts and ordinary
data.  I don't see how to keep content-type secret without lock-step
timing---which requires not just padding, but a habit of sending
packets with no application data, just padding, on clock ticks.  That's
extremely expensive for performance, if we make a general practice of it.


Brian Sniffen
Information Security
Akamai Technologies