Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

"Paterson, Kenny" <> Fri, 02 March 2018 10:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30CA9127136 for <>; Fri, 2 Mar 2018 02:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.079
X-Spam-Level: ***
X-Spam-Status: No, score=3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OUleV2yaKL4B for <>; Fri, 2 Mar 2018 02:17:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53BC512D94F for <>; Fri, 2 Mar 2018 02:17:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=byoS28yTERG4QSYmaqR2qDG8Ue49mDm9OeLJPxUfmvM=; b=TbGel4TgRJbBlqbqYnnHRZgfgQZ9DZRVE+iWmp2+JAgcrpb+SXzogBdlysoYA8zKGgmbkd21L2m6RIUPT9WhEu9dWSMR2n1ZTJacheWmBBSMcz9lKDL5eU/MZIWf9kQfBPHx4j4l7OqxLLrUhveqfN8Ggk9jEN3VYBFBpNTG1J0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Fri, 2 Mar 2018 10:17:21 +0000
Received: from ([fe80::c5a2:a1b:708e:7a80]) by ([fe80::c5a2:a1b:708e:7a80%14]) with mapi id 15.20.0548.014; Fri, 2 Mar 2018 10:17:21 +0000
From: "Paterson, Kenny" <>
To: Nikos Mavrogiannopoulos <>
CC: "<>" <>
Thread-Topic: [TLS] Possible timing attack on TLS 1.3 padding mechanism
Thread-Index: AQHTsaelJwznZeG3GEqfoybTZY5wZ6O8npwAgAAdYs8=
Date: Fri, 02 Mar 2018 10:17:21 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB2163; 7:3eiDPvsLX7sAq15nGMU9FDimf9TlX6joY8KP2Kv0lr5wt98cveoO9XGzubMYlZNgOSYylxk4BBMvkUUP7XuqE1n7t7VFcnnIa//93BpILpXdtoIkOPz3EHD0AhWGi+Y4y8MQiItss+iJveJ1tqT8tdjl3A0SHMB9/Jr4Kg38PqA2ioePsgFxnkq0kZu++Xx6TuYpwlsXV2asdIc2weMvWvmvv8JvFtNSOohJDL+fFllr8OszgK+yQcAVlSbVJGBI
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: eb4b5f82-f6af-49f3-f04b-08d58026c95b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM4PR0301MB2163;
x-ms-traffictypediagnostic: AM4PR0301MB2163:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231220)(944501238)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041288)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0301MB2163; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB2163;
x-forefront-prvs: 05991796DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39860400002)(39380400002)(199004)(189003)(377424004)(66066001)(3846002)(4326008)(105586002)(83716003)(86362001)(5250100002)(2900100001)(6916009)(74482002)(3660700001)(6246003)(229853002)(2950100002)(966005)(6116002)(3280700002)(72206003)(36756003)(14454004)(25786009)(551984002)(2906002)(97736004)(26005)(8936002)(6436002)(81166006)(68736007)(53546011)(478600001)(99286004)(81156014)(6506007)(102836004)(33656002)(6512007)(786003)(8676002)(316002)(5660300001)(106356001)(6486002)(305945005)(7736002)(76176011)(59450400001)(82746002)(53936002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB2163;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gu+c19VuYJKVKqqdLOK/rcF39CckAIZqX8WAcpJMtos+I6MOJIm90hWer0Gtx+32wO8X4/ejaxVvBmFWiVuDFaRSfzseW7I2qTvp9mvDihkOO4iC4JBOg9zNi5+neuZZeWM5LHC4fZCNPKo1NzCDakj4u1sy6jd00nMLW+A8l6k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: eb4b5f82-f6af-49f3-f04b-08d58026c95b
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 10:17:21.7526 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB2163
Archived-At: <>
Subject: Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
X-Mailman-Version: 2.1.22
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: Fri, 02 Mar 2018 10:17:27 -0000


> On 2 Mar 2018, at 08:32, Nikos Mavrogiannopoulos <> wrote:
>> On Thu, 2018-03-01 at 21:52 +0000, Paterson, Kenny wrote:
>> Hi,
>> I've been analysing the record protocol spec for TLS 1.3 a bit,
>> specifically the new padding mechanism. I think there's a possible
>> timing attack on a naïve implementation of de-padding. Maybe this is
>> already known to people who've been paying more attention than me!
>> Recall that the padding mechanism permits an arbitrary number of 00
>> bytes to be added after the plaintext and content type byte, up to
>> the max record size. This data is then encrypted using whichever AEAD
>> scheme is specified in the cipher suite. This padding scheme is quite
>> important for TLS 1.3 because the current AEAD schemes do leak the
>> length of record plaintexts. There should be no padding oracle style
>> attack possible because of the integrity guarantees of the AEAD
>> schemes in use. 
>> The idea for the timing attack is as follows. 
>> The natural way to depad (after AEAD decryption) is to remove the 00
>> bytes at the end of the plaintext structure one by one, until a non-
>> 00 byte is encountered. This is then the content type byte. Notice
>> that the amount of time needed to execute this depadding routine
>> would be proportional to the number of padding bytes. If there's some
>> kind of response record for this record, then measuring the time
>> taken from reception of the target record to the appearance of the
>> response record can be used to infer information about the amount of
>> padding, and thereby, the true length of the plaintext (since the
>> length of the padded plaintext is known from the ciphertext length).
>> The timing differences here would be small. But they could be
>> amplified by various techniques. For example, the cumulative timing
>> difference over many records could allow leakage of the sum of the
>> true plaintext lengths. Think of a client browser fetching a simple
>> webpage from a browser. The page is split over many TLS records, each
>> of which is individually padded, with the next GET request from the
>> client being the "response record". (This is a pretty simplistic view
>> of how a web browser works, I know!). The total timing difference
>> might then be sufficient for webpage fingerprinting, for example. 
>> I'm not claiming this is a big issue, but maybe something worth
>> thinking about and addressing in the TLS 1.3 spec.
>> There's at least a couple of ways to avoid the problem:
>> 1. Do constant-time depadding - by examining every byte in the
>> plaintext structure even after the first non-00 byte is encountered. 
>> 2. Add an explicit padding length field at the end of the plaintext
>> structure, and removing padding without checking its contents. (This
>> should be safe because of the AEAD integrity guarantees.) 
>> Option 2 is probably a bit invasive at this late stage in the
>> specification process. Maybe a sentence or two on option 1 could be
>> added to the spec.
> Hi,
> It was brought previously to the WG [0], and the bottom line was to push
> for any solution to implementations.

Thanks Nikos - sorry for missing your post from last August. At least I'm now only six months behind the curve :-)

> As of the "naïve implementation of de-padding", I wouldn't put like that.
> It is a straightforward method of de-padding after reading the draft, and
> I believe all implementations out there use that method.

Agreed. "Natural" would have been a better choice here. 



> regards,
> Nikos
> [0].