Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis

Manuel Pégourié-Gonnard <mpg@polarssl.org> Tue, 13 January 2015 16:40 UTC

Return-Path: <mpg@polarssl.org>
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 957671A8AE6 for <tls@ietfa.amsl.com>; Tue, 13 Jan 2015 08:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.096
X-Spam-Level: *
X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
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 h1oFHwnasEUG for <tls@ietfa.amsl.com>; Tue, 13 Jan 2015 08:40:08 -0800 (PST)
Received: from vps2.offspark.com (unknown [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934EF1A1B91 for <tls@ietf.org>; Tue, 13 Jan 2015 08:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Kg+Kb5MJLQnAsfGNxpFalf8Gc4M/LxfZ0wOe40bc9Vo=; b=fFpLl6RVVTQPr5/qn1h8r6LVdFw53DzegAL1RqsM3Khp1UWvDbCcPcHOCX9tdh7A8AlZk/xDrad4RXPprxAk7aSP0mnM+4vrEBGzVS0t8j0Uj5X4I52o4yDdB0TVc+y/dGF+KOGuJqwmbBojgXmPGYj1kmSf1ZPr6du/rnv9E8k=;
Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mpg@polarssl.org>) id 1YB4VR-00018r-TM; Tue, 13 Jan 2015 17:39:50 +0100
Message-ID: <54B54A5F.7020401@polarssl.org>
Date: Tue, 13 Jan 2015 17:39:59 +0100
From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@polarssl.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz> <D0D16976.3BD1D%kenny.paterson@rhul.ac.uk>
In-Reply-To: <D0D16976.3BD1D%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 88.165.216.11
X-SA-Exim-Mail-From: mpg@polarssl.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on vps2.offspark.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/S8XXDad343sHcKlPqCgeQb4E7R0>
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
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: Tue, 13 Jan 2015 16:40:12 -0000

On 06/01/2015 11:35, Paterson, Kenny wrote:
> On 06/01/2015 10:27, "Peter Gutmann" <pgut001@cs.auckland.ac.nz>; wrote:
> 
>> The MAC is whatever is negotiated for the session, and if you want a
>> shorter
>> one you can send the truncated-MAC extension (which, however, nothing
>> supports
>> AFAIK).  
> 
For some definition of nothing, which includes CyaSSL, MatrixSSL, PolarSSL and
apparently RSA BSAFE too:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Extensions

(FWIW, in PolarSSL we're going to disable it by default in the next major version.)

> It's good that nothing supports the truncated-MAC extension, because, in
> combination with TLS's support for variable length padding, it introduces
> a security vulnerability. See:
> 
> http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf
> 
> 
> which shows that if the tag size (MAC length) is shorter than the CBC-mode
> block size, then there's a distinguishing attack that can tell the
> difference between the encryption of a short message and a longer message
> (even though both are padded to the same size before encryption).
> 
But if one does not expect any length hiding, is there still a problem with
truncated MACs?

Manuel.