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

Tom Ritter <tom@ritter.vg> Tue, 27 January 2015 11:58 UTC

Return-Path: <tom@ritter.vg>
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 E23291A879E for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 03:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 4xsRq4lcBp7W for <tls@ietfa.amsl.com>; Tue, 27 Jan 2015 03:58:45 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9471A876C for <tls@ietf.org>; Tue, 27 Jan 2015 03:58:45 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id l13so3814389iga.5 for <tls@ietf.org>; Tue, 27 Jan 2015 03:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=24jOQwJ8aGzXnSSEQCPBW/uSvSRr3tCgCgSaiu7ESRI=; b=zO9ycBVgYw/+mhHIka/kD9KdF1gmEoS/7Cur2FnotLyug6vzH2envLlirV81sqKFIU DENhBjPj0fNAd5GtY6ykuyTcy1sezdObg3MKO7L1fldsd879ckG/LcgnQKO4xu8zXIGb PpnZvJ8OkLoqRGChKwhs/80K6YW9y1+W97Ly0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=24jOQwJ8aGzXnSSEQCPBW/uSvSRr3tCgCgSaiu7ESRI=; b=McsCOo/uQETuQNVH04xiN7KXE0Ethwfou9smIRn3eH5kFs931SiHMtv0Z+/6J6DMNn ET+hPOrJgTH7Ty5SdTG19IE4RlTk2Jff3ZmVdHkiRzgOU6phJjMHMOmF6adf733R46A1 qez4jKozNAj4KunkXHx1Z5AybILcvefI3XieEOMJcl7Fh18KpO4t7RvAZFZmzm+YF/kk XTFlADiYVqOGtdjztZ9x2QEb8xxeIEikT9fSb3I1f00sQIScrWcVH0vn5eBRVXbM+9rl sW69O2tuT7ocrmQFMN6wFLjBplCL/eQwnbm5jLuN2hzQrROeCSYzFNecAg8gwyZwu8/D SioA==
X-Gm-Message-State: ALoCoQkTQe+faKvbG5xeD3EMWieOv2AolZUpw42UMkiZFwsX7Xr4ksEPtM5b2lmeHqTkUalBl5A8
X-Received: by 10.107.137.77 with SMTP id l74mr891811iod.9.1422359924776; Tue, 27 Jan 2015 03:58:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.136.209 with HTTP; Tue, 27 Jan 2015 03:58:24 -0800 (PST)
In-Reply-To: <1422347617.16764.4.camel@redhat.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> <1422347617.16764.4.camel@redhat.com>
From: Tom Ritter <tom@ritter.vg>
Date: Tue, 27 Jan 2015 03:58:24 -0800
Message-ID: <CA+cU71koKfzaqqPoLGxSRhwAENr1ThRxfHQLkHPrfViK94NChw@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sDxLKFIn_hdPwU9mavJmeLZqjnk>
Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9=2DGonnard?= <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 11:58:47 -0000

On 27 January 2015 at 00:33, Nikos Mavrogiannopoulos <nmav@redhat.com>; wrote:
> 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-hiding0-2, 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).

Yes, draft-pironti-tls-length-hiding-02 does not put a penalty
everywhere. One of the initial discussions was "Let's not make it an
option, let's just have padding by default, and the folks who don't
want to use it will put a zero-length pad".  But to do so, AIUI, we
needed to stash a 2 byte padding length somewhere. (Hence paying the
cost.) People didn't want to pay the extra two bytes all the time, so
we started looking at using an alternate record type (possibly
encrypting them), or an extension as in the draft...

-tom