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

"Paterson, Kenny" <> Thu, 01 March 2018 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 358A1124D6C for <>; Thu, 1 Mar 2018 14:30:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.09
X-Spam-Level: **
X-Spam-Status: No, score=2.09 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 WcGinaD4zrFu for <>; Thu, 1 Mar 2018 14:30:43 -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 B348A124BFA for <>; Thu, 1 Mar 2018 14:30:42 -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=F6N9AqQy6JzP91ndc8cellv3gyDSOQdaJJBNCevlcXk=; b=oiwM4x0w8jkbr1trkDamsVYtio5aYNEMDLUCMVjmRP38CWeXrWO/kYgvjqs6h67GS7wr5i9Oafk8CUB0K2TIzrPLj4oL26DrAXVI/mTx8yEuheWYwdT9DxSLvZTcQFj+vupu5PtLS17Kry07MIqfM6AxfTXTKPUq5+N98kglva8=
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; Thu, 1 Mar 2018 22:30:40 +0000
Received: from ([fe80::c5a2:a1b:708e:7a80]) by ([fe80::c5a2:a1b:708e:7a80%14]) with mapi id 15.20.0548.014; Thu, 1 Mar 2018 22:30:40 +0000
From: "Paterson, Kenny" <>
To: Eric Rescorla <>
CC: "<>" <>
Thread-Topic: [TLS] Possible timing attack on TLS 1.3 padding mechanism
Thread-Index: AQHTsaelJwznZeG3GEqfoybTZY5wZ6O79ZSAgAAA9oA=
Date: Thu, 01 Mar 2018 22:30:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/f.28.0.171108
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1892; 7:cGkfj6WZssrSysiniORTh+dXW2F7H4cHQl65Q2+qAvoTx3+hgULSPy4ll/hq1J6BmGgPYTYs1yIRf/YI3gKWVUc/8So7G9QEa8iLEY8wgmeUds+JDEcxhhYvnBodc0QrmcjHtAWFRg84LyCSdtLH5dAS6pja2PgBBG45vcJh2e5xx7AATgG9sjSDFKh+Q2C0TzZMF8N7QTKQgEYiigVFxh1aKYtNimHm18+V8G+uI9X0Q1s6DZe1SeoO8l2+p13w
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: da7eae7a-29b4-49e9-8eaf-08d57fc41004
x-microsoft-antispam: UriScan:(161990435356232); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7153060)(7193020); SRVR:AM4PR0301MB1892;
x-ms-traffictypediagnostic: AM4PR0301MB1892:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(161990435356232);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231220)(944501232)(52105095)(3002001)(10201501046)(6041288)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR0301MB1892; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1892;
x-forefront-prvs: 05986C03E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(396003)(346002)(366004)(39860400002)(13464003)(199004)(189003)(5660300001)(186003)(6116002)(36756003)(3280700002)(58126008)(74482002)(4326008)(6246003)(3846002)(551984002)(25786009)(53936002)(102836004)(59450400001)(14454004)(26005)(2906002)(97736004)(86362001)(66066001)(53546011)(316002)(6916009)(99286004)(83716003)(6506007)(786003)(2950100002)(966005)(5250100002)(6512007)(106356001)(3660700001)(8676002)(76176011)(81156014)(2900100001)(81166006)(72206003)(105586002)(6436002)(6306002)(68736007)(305945005)(8936002)(7736002)(6486002)(229853002)(478600001)(82746002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1892;; 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: YgnMNDselTe4BrFKdrThFEoRbXrXS9Buhopcl9YbJ7TQpbXxS+cq24IuSRmi7Tw29Ak2a+Uwf3cievHaL/om3BnRoSQeGpVyTeZF6Kh5i917C4PbNn79HjJWCboP7lTFOPIY969lhA11whxIDPxMAjh0+iyU2meyqUaU+Zo9tGQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: da7eae7a-29b4-49e9-8eaf-08d57fc41004
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 22:30:40.1532 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1892
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: Thu, 01 Mar 2018 22:30:45 -0000

Hi Ekr.

Ah that's great, thanks - and I think the text in the Appendix already addresses the issues very well.

Sorry for the bandwidth consumption.



-----Original Message-----
From: Eric Rescorla <>
Date: Thursday, 1 March 2018 at 22:27
To: "Paterson, Kenny" <>
Cc: "" <>
Subject: Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

    Hi Kenny,
    Yes, this is something we are aware of. Here's the relevant text from the document:
    I don't think we're likely to change the protocol, but if you have some proposed text
    that you think would be informative above and beyond what we already have, please
    send it along.
    On Thu, Mar 1, 2018 at 1:52 PM, Paterson, Kenny 
    <> wrote:
    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.
    TLS mailing list