Re: [TLS] Encryption of TLS 1.3 content type

Yoav Nir <> Mon, 28 July 2014 20:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D74001A00FE for <>; Mon, 28 Jul 2014 13:04:52 -0700 (PDT)
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 H7Li-sCZFXPj for <>; Mon, 28 Jul 2014 13:04:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 819771A00FF for <>; Mon, 28 Jul 2014 13:04:50 -0700 (PDT)
Received: by with SMTP id m15so7889495wgh.29 for <>; Mon, 28 Jul 2014 13:04:49 -0700 (PDT)
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=/hSEtp3O6209NT/gisWxx4kd43D9JinCSLsp6XW+taQ=; b=NFGxNKSMHLzM90zb759Rvn/Uc+ueEQVILnXpTNGy2x9uVR5jRgJ5E2JOF7Pj99KHMY 2xuN1Xt4FUaudxWbyN5ym1Pe0EzTl0Ihm94MFNIR7IiakchF3KPejdssXCHalkYhKBsE zRzfr+ekL19YbcyMwORwkgJgd3ED2hoBeLFL21Jdit34GSWeGU1BveTiRrSxYgAYLZus i8H/fNTjTkhILuOAN0GQnI6cBya0JNaEpejbuKDWkV4qsk9uC3HpxSclA4eJ39p3JlCm /M54fDSGHJSOl3q1PqAvxypi50ZchYZU9QuxQzv9cf67t6QJ/+49m3xnO84UeKqrFBYl hQHw==
X-Received: by with SMTP id n10mr34850980wia.41.1406577888104; Mon, 28 Jul 2014 13:04:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id fs3sm34809730wic.20.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:04:47 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 28 Jul 2014 23:04:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Brian Sniffen <>
X-Mailer: Apple Mail (2.1878.6)
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 20:04:53 -0000

On Jul 28, 2014, at 6:35 PM, Brian Sniffen <> wrote:

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

Challenge accepted

Assume that the path is deemed wide enough to carry 3 MB/s. We will limit ourselves to slightly less than that, so let’s say 2000 records of 1400B plaintext a second in each direction.

The sender (whether client or server) has two buffers, a system buffer and a data buffer. The application writes to the data buffer. If there’s an error, or the application wishes to close, an alert is placed in the system buffer.

Every half millisecond, the TLS stack performs the following:

* if the system buffer is not empty, retrieve an alert, pad to 1400 bytes, encrypt, and send.
* else if the data buffer is empty, generate a record with 1400 pad bytes, encrypt and send.
* else if the data buffer contains at least 1400 bytes, create a 1400-byte record, remove 1400 bytes from the buffer, encrypt and send.
* else create a record with all remaining data, pad to 1400 bytes, encrypt and send.

This is assuming that the attacker can’t distinguish the number of “ifs” you ran through. Otherwise, don’t send the record, but store it and send it the next time the timer expires. That also takes care of any timing side-channel you have in your encryption function.

Note that I’m not advocating doing this with TLS. IPsec has this feature and to my knowledge nobody uses it.