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

mrex@sap.com (Martin Rex) Mon, 02 December 2013 23:08 UTC

Return-Path: <mrex@sap.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 E6C4E1ADF9B for <tls@ietfa.amsl.com>; Mon, 2 Dec 2013 15:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 tx7X08LEDCiN for <tls@ietfa.amsl.com>; Mon, 2 Dec 2013 15:08:03 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EBB4D1ADF9D for <tls@ietf.org>; Mon, 2 Dec 2013 15:08:02 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rB2N7wf6029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 00:07:58 +0100 (MET)
In-Reply-To: <1385826600.11639.25.camel@aspire.lan>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Date: Tue, 3 Dec 2013 00:07:58 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131202230758.8B71B1AB1F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
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
Reply-To: mrex@sap.com
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, 02 Dec 2013 23:08:06 -0000

Nikos Mavrogiannopoulos wrote:
> 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.

Very important observation.

Peter's proposal changes AtE to EtA, but does not currently address
the predictable IV for SSLv3 & TLSv1.0.  As it turns out, EtA will
not protect from BEAST, because it is "generically" secure only against
decryption oracles.  BEAST was exploiting an _encryption_ oracle.

:-)

-Martin