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

Nikos Mavrogiannopoulos <nmav@redhat.com> Sat, 30 November 2013 16:00 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E31AE44E for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 08:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK6Nbabx61-w for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 08:00:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 606221AE454 for <tls@ietf.org>; Sat, 30 Nov 2013 08:00:22 -0800 (PST)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAUFo3s4030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 10:50:05 -0500
Received: from [10.10.55.105] (vpn-55-105.rdu2.redhat.com [10.10.55.105]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAUFo0rG019640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Nov 2013 10:50:01 -0500
Message-ID: <1385826600.11639.25.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 30 Nov 2013 16:50:00 +0100
In-Reply-To: <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp> <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi> <1385767358.5937.18.camel@aspire.lan> <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 30 Nov 2013 16:00:24 -0000

On Fri, 2013-11-29 at 17:23 -0800, Watson Ladd wrote:

> > Contrary to popular opinion on this list AtE is a standard way of
> > operation with no flaws known unless used with an unauthenticated pad
> > (as in TLS). When SSL 3.0 was designed AtE was believed to be the
> > conservative approach comparing to EtA.
> The passive voice is doing a lot of work here. Bellare and Namparah
> showed that EtA is generically secure,
> AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
> "no flaws known"!="proved to be secure"

Proven to be secure doesn't mean that attacks don't exist. The TLS
padding scheme was proven to be secure prior to be broken; ironically by
the same person who made the proof. Attacks work by playing outside the
requirements of the proof.

Nevertheless, there is much more recent work on EtA vs AtE, that
actually proves AtE secure (not "generically" as you pose, you just need
a decent cipher). You may check "The order of encryption and
authentication for protecting communications (or: How secure is SSL?)".
There are even newer papers than that, it is just this that came to
mind.

regards,
Nikos