Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 09 September 2013 14:17 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37021E820A for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6dbM0ATwGND for <tls@ietfa.amsl.com>; Mon, 9 Sep 2013 07:17:31 -0700 (PDT)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2511E81D1 for <tls@ietf.org>; Mon, 9 Sep 2013 07:11:38 -0700 (PDT)
Received: from mail29-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 14:11:29 +0000
Received: from mail29-co9 (localhost [127.0.0.1]) by mail29-co9-R.bigfish.com (Postfix) with ESMTP id 7FB611A017B for <tls@ietf.org>; Mon, 9 Sep 2013 14:11:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:134.219.208.108; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB02.cc.rhul.local; RD:exch-hub02.rhul.ac.uk; EFVD:NLI
X-SpamScore: -35
X-BigFish: VPS-35(zzbb2dI98dI154cP9371I1432Idb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h5eeeK8275bh8275dhz2dh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT003.eurprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail29-co9 (localhost.localdomain [127.0.0.1]) by mail29-co9 (MessageSwitch) id 1378735827149689_12016; Mon, 9 Sep 2013 14:10:27 +0000 (UTC)
Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.231]) by mail29-co9.bigfish.com (Postfix) with ESMTP id 20D59320059 for <tls@ietf.org>; Mon, 9 Sep 2013 14:10:27 +0000 (UTC)
Received: from EXCH-HUB02.cc.rhul.local (134.219.208.108) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 14:10:26 +0000
Received: from CO9EHSOBE038.bigfish.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.108) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 9 Sep 2013 15:10:24 +0100
Received: from mail162-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 14:10:23 +0000
Received: from mail162-co9 (localhost [127.0.0.1]) by mail162-co9-R.bigfish.com (Postfix) with ESMTP id DF7A8120094 for <tls@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Mon, 9 Sep 2013 14:10:22 +0000 (UTC)
Received: from mail162-co9 (localhost.localdomain [127.0.0.1]) by mail162-co9 (MessageSwitch) id 1378735820188557_19224; Mon, 9 Sep 2013 14:10:20 +0000 (UTC)
Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.250]) by mail162-co9.bigfish.com (Postfix) with ESMTP id 296ACE00AB; Mon, 9 Sep 2013 14:10:20 +0000 (UTC)
Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 14:10:20 +0000
Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.78]) by AMXPRD0310HT003.eurprd03.prod.outlook.com ([10.255.55.38]) with mapi id 14.16.0353.003; Mon, 9 Sep 2013 14:10:19 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Alfredo Pironti <alfredo@pironti.eu>, Peter Saint-Andre <stpeter@stpeter.im>
Thread-Topic: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)
Thread-Index: AQHOrV7JqCYZI8YfRkeamC+FHpvRkpm9gp+A
Date: Mon, 9 Sep 2013 14:10:18 +0000
Message-ID: <CE538FA7.A524%kenny.paterson@rhul.ac.uk>
In-Reply-To: <CALR0uiKTySMMRBKC8pDAvg_Fy8m8SA+Gj-te6WnQvB9w=MLcfw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.255.40.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D9B9CB1449141947B398388171BA7A89@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%36694$Dn%PIRONTI.EU$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-FOPE-CONNECTOR: Id%36694$Dn%STPETER.IM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2013 14:17:44 -0000

On 09/09/2013 14:15, "Alfredo Pironti" <alfredo@pironti.eu> wrote:

>On Sun, Sep 8, 2013 at 4:59 AM, Peter Saint-Andre <stpeter@stpeter.im>
>wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> [old thread alert!]
>>
>> On 7/1/13 3:02 AM, Lewis, Nick wrote:
>>>> While people are looking at that, there's also the
>>>> encrypt-then-MAC draft,
>>>> 
>>>>http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-
>>>>03.txt,
>>>>
>>>>
>> which has been stable for about as long, has already been deployed by
>>>> several vendors, and for which TLS extension 0x10 has been de
>>>> facto claimed, so it'd be good to get this published to
>>>> legitimise the use (and to document what's already being deployed
>>>> in production).
>>>
>>> As I recall there were three proposals for resolving the padding
>>> bug in TLS
>>>
>>> 1.       An extension for Pad First (i.e. padding before an
>>> otherwise standard TLS mode of operation)
>>>
>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>>
>>> 3.       The replacement of each existing cipher suite with an
>>> equivalent AEAD one
>>>
>>> Was any consensus achieved as to the best approach?
>>
>> I never saw further discussion on this topic. Are there I-Ds for each
>> approach? #3 seems onerous to me (and doubling the number of cipher
>> suites doesn't seem like a desirable outcome), and as far as I can
>> tell there's no specification for #1.
>
>Approach #1 is defined in
>http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 and we
>have a couple of implementations for it. The main purpose of the I-D
>is to provide means to conceal the payload length within TLS
>fragments; however, a valuable byproduct is to also eliminate the
>recent padding oracle attacks. The I-D applies to all currently
>defined ciphers (block, stream, and AEAD). I'd like to hear your
>comments about it.

Two comments, one on Approach #1, the other on Approach #2:

1. There is some formal support for the "Pad-then-encrypt-then-MAC"
approach being used in the above Approach #1 in the following paper:

Kenneth G. Paterson and Gaven J. Watson

Authenticated-Encryption with Padding: A Formal Security Treatment
Cryptography and Security: From Theory to Applications

Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.

http://link.springer.com/book/10.1007/978-3-642-28368-0



See in particular, Theorem 8 in the paper.

Unfortunately, this paper is behind Springer's paywall. For those on the
list without access, you can access the same content in Chapter 5 (Theorem
5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:

http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf



2. Approach #2 is well supported by theory and is more cryptographically
robust (in the face of bad implementations), provided the involved MAC
algorithm is strong enough.

I briefly reviewed the literature for the state-of-the-art on attacks
against HMAC-H for hash algorithm "H". (See for example
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L.
Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus
more recent work, e.g. Peyrin et al. at Asiacrypt 2012.)

In TLS, we essentially have H = MD5, SHA-1 or SHA-256.  In view of the
literature, of these, I'd recommend deprecating MD5 as the hash if
Approach #2 were to be adopted: current attacks do not seriously threaten
it, but taking a fairly conservative approach seems appropriate here.

Best wishes,

Kenny