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

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 27 January 2015 08:33 UTC

Return-Path: <nmav@redhat.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 5607A1A1B43 for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 00:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 6xgm2v-DTij3 for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 00:33:44 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 31DD31A700B for <tls@ietf.org>; Tue, 27 Jan 2015 00:33:44 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0R8Xf7U004959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 27 Jan 2015 03:33:41 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0R8XcOQ030165 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2015 03:33:39 -0500
Message-ID: <1422347617.16764.4.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Tom Ritter <tom@ritter.vg>
Date: Tue, 27 Jan 2015 09:33:37 +0100
In-Reply-To: <CA+cU71n_wJQP-wvBpxU6z=a2zcjRFovdrb2FCjAUQFrJvs1pGA@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73AAF525B9@uxcn10-tdc05.UoA.auckland.ac.nz> <D0D16976.3BD1D%kenny.paterson@rhul.ac.uk> <54B54A5F.7020401@polarssl.org> <D0DB0820.3C588%kenny.paterson@rhul.ac.uk> <CACsn0c=oYuUhkPi2QO=qPy95X4v+xXViTyi+XzyRrO1BKLnnLg@mail.gmail.com> <D0DB1039.3C5D9%kenny.paterson@rhul.ac.uk> <CACsn0ck-2_348SkASvkCrP7r3HoD-G8t590WRzWkQpj6TjBMqg@mail.gmail.com> <CABkgnnWLUsKuJ71dbpSps5bErbrjGnYe-_BjDpJGmMkD-O0BUw@mail.gmail.com> <54B65AF0.1080503@metaparadigm.com> <CABkgnnUmoA4mMqbgVaKgebmC-PzvSBeRQ_=eoCSaNp9C2mtg=Q@mail.gmail.com> <CA+cU71=Zs3zkfsxiYev-E9Wqg=nYTtUbiizoJCJ4QUVc=qpRRw@mail.gmail.com> <CABtrr-VJRqw6oG6e7DxuBaXq8DM2Y9WxLjJ=Z9BEchceoh00ow@mail.gmail.com> <CA+cU71n_wJQP-wvBpxU6z=a2zcjRFovdrb2FCjAUQFrJvs1pGA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_UXUx7Cfs5du9UmYPVCxMtnW42U>
Cc: Manuel Pégourié-Gonnard <mpg@polarssl.org>, "tls@ietf.org" <tls@ietf.org>
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, 27 Jan 2015 08:33:47 -0000

On Mon, 2015-01-26 at 13:08 -0600, Tom Ritter wrote:

> Length Hiding in TLS gets you good protection against passive captures
> and lets you deploy the mechanism independent of building in the
> feature at Layer 7 or above in multiple applications, application
> protocols, web frameworks, etc.  (Some of which may be old and
> unmaintained, but still running lots of services on the Internet.)
> 
> >From my recollection at Denver:
>  - Consensus was we didn't want to pay a 2-byte penalty to put padding
> in everywhere by default
> - Rough Consensus was padding without paying a penalty was something
> reasonable to pursue
 
If that refers to draft-pironti-tls-length-hiding-02, I believe these
comments are mislead. There is no penalty "everywhere" as you pose it.
Peers who need no padding don't use the additional length bytes. Only
peers who need to hide length use these two bytes. This is not a
penalty, as it can simply be considered part of the pad (min size of pad
= 2).

regards,
Nikos