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

Russ Housley <> Wed, 24 December 2014 15:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3C851A8A7C for <>; Wed, 24 Dec 2014 07:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IWlQvavZ48t7 for <>; Wed, 24 Dec 2014 07:17:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EFDA91A8A7A for <>; Wed, 24 Dec 2014 07:17:45 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 7B3F09A400D for <>; Wed, 24 Dec 2014 10:17:35 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zhr7okQGXDLK for <>; Wed, 24 Dec 2014 10:17:14 -0500 (EST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTP id 33CF99A4001 for <>; 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 <>
In-Reply-To: <>
Date: Wed, 24 Dec 2014 10:17:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
X-Mailer: Apple Mail (2.1085)
Subject: Re: [TLS] AAED ciphers: AES-GCM vs AES-EAX/AES-CCM: a meta-analysis
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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