Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 14 November 2013 16:00 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 2A1C011E8184 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 r2EiiFss7DMg for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:00:20 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 502BE11E8176 for <tls@ietf.org>; Thu, 14 Nov 2013 08:00:20 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id ev20so1740218lab.39 for <tls@ietf.org>; Thu, 14 Nov 2013 08:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gNQmlhOVhNMQquwTuYvtgq2IVzvAnbnd8dBwVTpG6rI=; b=ak+izzG/p8SoTgisq2Mk2PlYanWErF01oPd4UTL9TwxGUypdsan3HWgiUa4qh9Wg9s Eqnhhwcapokjt3+3WfzwLEK1i43lE2hJXZPPtfKGGAU1bqNfXdw9T3ZFvv6Z4IOp14rS HV5XiBgw0E24b28b50KMhcPbnm5ICyGlUu0HFLbuJLRPTG67LIbFCEoYfNH/j1aJDdO0 TBRPKCVab1b3I7wFixNGz4Tite/wdAaRQ9fr87xTbe/YFU5zHF3x1y0IY5fQGLlv1yz7 LOjR3Qm22w8TcJ452Z2O9Vc22tsnsuOGfInfClrgdntLSrNK65JMB61PmOyuipu3IClC B3PA==
MIME-Version: 1.0
X-Received: by 10.112.144.105 with SMTP id sl9mr1181069lbb.37.1384444818816; Thu, 14 Nov 2013 08:00:18 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Thu, 14 Nov 2013 08:00:18 -0800 (PST)
In-Reply-To: <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
References: <007d01cee0b9$ffbe8290$ff3b87b0$@org> <20131114150531.66A001AA90@ld9781.wdf.sap.corp> <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
Date: Thu, 14 Nov 2013 17:00:18 +0100
X-Google-Sender-Auth: fS2gN0LOBNFycbrwyg1StpzTkHk
Message-ID: <CAJU7za+N3KU1Mhfi3oXaAZd2kkCQOW3a59ZBrfQhdtKzVqA-6g@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset="UTF-8"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 16:00:21 -0000

On Thu, Nov 14, 2013 at 4:47 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:

> 1. EtA discards a malicious packet earlier than AtE. This means the packet
> is processed by less programm code and the attacker has less chance to
> trigger a vulnerability in the program code (We are talking buffer overflow
> [etc!] here as well and not just crypto-vulns).

This is an often repeated argument. How many of these attacks are we
currently seeing in TLS that doesn't use EtA? None. The difference in
processing is really negligible to be used in a serious attack.

> 2.With AtE there is a correlation between the MAC and the plaintext. This
> turns any known-plaintext attack into a ciphertext only attack and you
> should not have a correlation even if this correlation can not be exploited
> today by public cryptanalytic means.

I don't understand your point. How would they work when the MAC is encrypted?

Both EtA and AtE have weak points, depending what you trust more, the
cipher or the MAC. With EtA you need to trust the MAC as any attacker
has access to the MAC and the actual authenticated data (which is the
ciphertext).

regards,
Nikos