Re: [TLS] TLS1.3

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 08 February 2013 22:51 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 EA95021F8814 for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 14:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzQYjUvsKKMC for <tls@ietfa.amsl.com>; Fri, 8 Feb 2013 14:51:14 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6121F87B6 for <tls@ietf.org>; Fri, 8 Feb 2013 14:51:14 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id dq12so3443874wgb.24 for <tls@ietf.org>; Fri, 08 Feb 2013 14:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=aQEgJYwmDUO5bOcyH+0S5g4URi/Yy7woZ+cFdEm4B5w=; b=HAGh5H8ltUER57CLTokvdhB+Kwuj4O4ij+Q8rFhaMVC67zGhxeZfEv9+0lV9YYNZCO SfWUQDFmXED+57zxk2TZ/Fz7VBa/kWXanoBXejkfipFvA2W+/dIcrzLsLMPM454uDQ9J cQ+KEyP1I1z9CNxDaS7WJohVTHd7mkKGJVroflogqyHGFkZuUZkVtibYYnOAKkBUF0jf 9o5HuGszftk+tB9QFUmPNF1t9YA3a5P0kEXA08V+kGar8ZWLD+dlAkKLVk3PiA8J9deI AfeljKKkREQq8cDg4j+mDUH3c5KrxeR+ns4Yt+O0mr/wHrOn9d3K3O8/v0ELMTOJ9dH1 jaRA==
X-Received: by 10.180.104.10 with SMTP id ga10mr5212458wib.23.1360363873314; Fri, 08 Feb 2013 14:51:13 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id s8sm16861209wif.9.2013.02.08.14.51.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 14:51:12 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5115815B.5000909@gnutls.org>
Date: Fri, 08 Feb 2013 23:51:07 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
References: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> <CAJU7za+NPT03YoJc=xKkA23=aw6kq2DSgs3Tpj_cA_dP2xCf6w@mail.gmail.com> <B132B06E59C4A540A03C3393F53BC07C407DE1F8@EXCH-MB01.cc.rhul.local>
In-Reply-To: <B132B06E59C4A540A03C3393F53BC07C407DE1F8@EXCH-MB01.cc.rhul.local>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS1.3
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: Fri, 08 Feb 2013 22:51:15 -0000

On 02/08/2013 02:03 PM, Paterson, Kenny wrote:

>> There is nothing wrong with MAC-then-encrypt,

> 
> I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000
> and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good
> reasons to be suspicious of MAC-then-encrypt from a theoretical
> perspective.


It could be, and I cannot offer any insight on whether these theoretical
weaknesses, have any practical effect.

However, the switch from MAC-then-Encrypt to Encrypt-then-MAC mode of
operation is a radical move that does not affect only the CBC ciphers
(e.g. RC4-SHA1 is also MAC-then-Encrypt).

> And in practice, time and again it's proven to be problematic. And

> not just in TLS (see for example my paper with Jean Paul Degabriele
> at ACM-CCS 2010 about MAC-then-encrypt configurations of IPsec.
> TL;DR: we broke them all).


I understand, and such attacks can indeed occur if there are encrypted
data that are left unauthenticated by the MAC (e.g., as the pad is in
TLS now). My sentence referred to a MAC-then-encrypt operation that
encrypts and authenticates all data (including any pads).

regards,
Nikos