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

Russ Housley <housley@vigilsec.com> Wed, 24 December 2014 15:17 UTC

Return-Path: <housley@vigilsec.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 A3C851A8A7C for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 07:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 IWlQvavZ48t7 for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 07:17:46 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA91A8A7A for <tls@ietf.org>; Wed, 24 Dec 2014 07:17:45 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 7B3F09A400D for <tls@ietf.org>; Wed, 24 Dec 2014 10:17:35 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zhr7okQGXDLK for <tls@ietf.org>; Wed, 24 Dec 2014 10:17:14 -0500 (EST)
Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 33CF99A4001 for <tls@ietf.org>; Wed, 24 Dec 2014 10:17:14 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <54961200.6030506@metaparadigm.com>
Date: Wed, 24 Dec 2014 10:17:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <05961945-E0EE-4842-B051-BEEE892D0C66@vigilsec.com>
References: <549538E5.7050109@metaparadigm.com> <5495BE11.4040703@iki.fi> <54961200.6030506@metaparadigm.com>
To: IETF TLS <tls@ietf.org>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mM9Tg_aj4o3IAHVcZ-oi5Hk_Iyk
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: Wed, 24 Dec 2014 15:17:47 -0000

The folks doing the DTLS profile for low-end devices have chosen AES-CCM because they have hardware support for it.  I think we should include it to promote interoperability.

Russ


On Dec 20, 2014, at 7:19 PM, Michael Clark wrote:

> On 21/12/14 2:21 am, Tapio Sokura wrote:
>> Hello,
>> 
>> On 20.12.2014 10:52, Michael Clark wrote:
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_128_EAX_SHA256
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_256_EAX_SHA384
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_128_EAX_SHA256
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_256_EAX_SHA384
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_128_CCM_SHA256
>>>      CipherSuite TLS_DHE_DSS_WITH_AES_256_CCM_SHA384
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_128_CCM_SHA256
>>>      CipherSuite TLS_ECDHE_DSS_WITH_AES_256_CCM_SHA384
>> A bit off-topic on the actual question, but: Is DSS used anymore? Should
>> these be ECDSA instead?
> 
> Thanks. Yes. I did mean ECDSA, the eliptic curve variant of DSA (DSS).
> It was a mistake on my part.
> 
> Someone mentioned off list mentioned the AEAD ChaCha20-Poly1305 draft,
> however I note the authenticator is still 16 bytes (128 bits). I had
> seen the draft but wasn't sure if it was going to be included in TLSv1.3.
> 
> It occurred to me that a (perhaps not fair) comparison would be with
> using MD5 which is 128 bits. MD5 has collisions. GHASH finite field and
> the cipher based MACS (including Poly1305) should be safe in this regard
> due to their construction. My understanding is that cipher based MACS
> are vulnerable to attacks that reverse rounds of the cipher after a
> certain number of texts have been seen (birthday attack). The fact that
> the nonce has a short lifetime probably makes this intractible however I
> began wondering about the 'designed in' lower entropy in GCM (IV suffix
> on first block 32-bits starting at 0x00000001 versus incrementing the
> whole IV and preserving entropy). Both this; and properties of the
> parallelizability GHASH construction. The IV construction effectively
> means only 96 bits need to be brute forced to forge an authenticator
> (unless in practice a random initial counter was used) as we know the
> counter for each block. It seems to be a designed in weakness along with
> excellent parallelizability. CCM and EAX are not exploitable in this manner.
> 
> The main point was besides eavesdropping potential, was the ability of
> an attacker to inject random bit errors by finding authenticator
> collisions; i.e. message integrity; and also the parallelizability of
> GCM. Parallelizability lowering the barrier to anyone with sufficient
> resources. AES-GCM and AES-CCM are the only two implemented AEAD
> ciphers. The later is not present in openssl, boringssl, libressl (last
> time I looked).
> 
> The thought that occurred to me was the idea of having a 256-bit
> authenticator with a 256-bit cipher. In practice we use 256-bit and
> 384-bit MACs. It's whether we consider the AEAD MAC as an "error
> correction code" or a "cryptographic MAC". People are widely deploying
> 256-bit and 384-bit MACs in areas where a "cryptographic MAC" is
> required. I guess it is also dependent on the time window (which in TLS
> is short) however someone with acres/hectares of computers could make a
> DHT (Distributed Hash Table). Drives are cheap and DHTs are fast for
> vast amounts of data. Reasoning is 32 bits lost entropy, n bits in
> storage, m bits computed online (from looking at table based GHASH).
> 
> OMAC1/CMAC is limited to the block size of the underlying cipher which
> is 128 bits even with AES-256. EAX just seems simpler than CCM.
> 
> Just thought I would question the convention and established thought...
> 
> Cheers,
> Michael.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls