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

Michael Clark <michael@metaparadigm.com> Thu, 25 December 2014 01:34 UTC

Return-Path: <michael@metaparadigm.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 9074E1A6F68 for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 17:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.468
X-Spam-Level:
X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 fyPDMVB8k6kg for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 17:34:47 -0800 (PST)
Received: from klaatu.metaparadigm.com (klaatu.metaparadigm.com [67.207.128.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF281A6F67 for <tls@ietf.org>; Wed, 24 Dec 2014 17:34:47 -0800 (PST)
Received: from monty.local (unknown.maxonline.com.sg [58.182.90.50] (may be forged)) (authenticated bits=0) by klaatu.metaparadigm.com (8.14.4/8.14.4/Debian-4) with ESMTP id sBP1tSca012451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Dec 2014 01:55:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metaparadigm.com; s=klaatu; t=1419472533; bh=QhtWBZ4v24o24MGxhBhUWc1tWa2Ek4y9XAHtaywuy/k=; h=Date:From:To:Subject:References:In-Reply-To:From; b=wEmBGgidE2A2TThutCADZ0lmTgN7GOL5sBqL939VyYvppnCunB/No8Y9me26fgStl 5mEjemaNVAII6nuGL/vef5zOclERlrg8+gAEPEsTFrRQ/eImrUJZQE6qocZB9wP+tk wcUdJpw/Txgj7IYBF+BbsbFcPuEOsRAStULjKSaQ=
Message-ID: <549B6998.6050405@metaparadigm.com>
Date: Thu, 25 Dec 2014 09:34:16 +0800
From: Michael Clark <michael@metaparadigm.com>
Organization: Metaparadigm Pte Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF49636@uxcn10-tdc05.UoA.auckland.ac.nz> <549B61E4.8080301@metaparadigm.com>
In-Reply-To: <549B61E4.8080301@metaparadigm.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.4 at klaatu.metaparadigm.com
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XmeXIu4WVumr91MxOHF3_WV1CEs
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: Thu, 25 Dec 2014 01:34:48 -0000

The other point being to remove MAC-then-encrypt from TLSv1.3, not
necessarily AES-CBC (as its non parallelism is a good property in
certain situations).

The principle is considering TLSv1.3 from a 'profile' perspective and
that the 'known problematic' MAC-then-encrypt could be supported by
implementations that choose to offer TLSv1.2 (and older) profiles and
drop encrypt-then-MAC and make MAC-then-encrypt mandatory in the TLSv1.3
profile. i.e. a clean up, and improvement to auth integrity.

The principle being we shouldn't preserve back compatibility by
incorporating old baggage into to the new spec, rather have a design
that allows implementations to support older profiles.

This would make the spec simpler. TLsv1.3 would be completely
encrypt-then-MAC including the ability to augment AEAD ciphers with more
authentication bits. i.e. symmetrical (except for a special case of
hmac_null where the auth bits equals the tag bits of the AEAD cipher and
how the AD is handled for encrypt-then-MAC with an AEAD cipher).

my 2 cents.

On 25/12/14 9:01 am, Michael Clark wrote:
> Hi Peter,
> 
> Someone pointed out RFC 7366 to me off list. I will read. I like the
> idea of encrypt-then-MAC being a core requirement for TLSv1.3.
> 
> Before I've read through can we do this with it?
> 
> AES-256-GCM + hmac_null   = 128 bits authentication
> AES-256-CBC + hmac_sha128 = 128 bits authentication
> 
> AES-256-GCM + hmac_sha128 = 256 bits authentication
> AES-256-CBC + hmac_sha256 = 256 bits authentication
> 
> AES-256-GCM + hmac_sha256 = 384 bits authentication
> AES-256-CBC + hmac_sha384 = 384 bits authentication
> 
> I like the idea of >= 256 bits authentication, and the idea of the
> combination of a cipher based MAC and PRF based MAC for AES-GCM, given
> the properties of the AES-GCM CTR mode 'variant' and GHASH GF(2^128).
> 
> Michael.
> 
> 
> On 24/12/14 2:15 pm, Peter Gutmann wrote:
>> Michael Clark <michael@metaparadigm.com> writes:
>>
>>> I have been doing some independent research on TLS AEAD ciphers and decided
>>> to share a meta-analysis on AES-GCM versus AES-EAX/AES-CCM
>>
>> If you're going to look at these, what about also looking at encrypt-then-MAC,
>> which is another AEAD mechanism?
>>
>> Peter.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>