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

Tom Ritter <> Mon, 26 January 2015 19:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 73D651ACEA5 for <>; Mon, 26 Jan 2015 11:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tQ16pbvg9xiJ for <>; Mon, 26 Jan 2015 11:08:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 187FC1ACE9E for <>; Mon, 26 Jan 2015 11:08:44 -0800 (PST)
Received: by with SMTP id a13so11389igq.0 for <>; Mon, 26 Jan 2015 11:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TbZbY+O0fUVypHQzMBqRaMb5fvZaSvb6gUk8WuNFYgA=; b=QhJpAavKLCmFsnbUOH/Iqikh8/ExBfSVrv1YFFrNrKt7SYIkp29245y6wFwExpFMAQ 9kHfQIes3+P0HJk1JAQ2wCqCqNtoGY08cATFGt05bKFPrqgWD9oN16lPux7I/wjUWlXl OZ2GApBmNIAieMpBjwt8J9hKZp0ZgSgckHXiI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=TbZbY+O0fUVypHQzMBqRaMb5fvZaSvb6gUk8WuNFYgA=; b=Zkkd4iEEI4UCJGvx8FGbjF1LC2hLc3veHTxk6CENkdl7q72cO8g2eA3xmZ8ULrsjfA EywKuO4ripl+ddwFTOrh9mkVYh7jI9gzaHAuBcF4tbiwfGwwvtMELYlJrnC/ImcfASXs RJtp0epJ5wavEeECozkS1hytV/JkWHr4uoznpIwp8ZvqJQVV47FQg6hgM6zgHhaOKUAH +KBQRzHaKegpR8QjI0OpS7ISV731qK9Itl4lR/7eVwRR/Z4NrklACftEG3yNvzzclhTD bxvNC6U5kLm2eK3c1a9tImyWGiP6y9EurJYNu6jspgJTiRHCHPH137uDDBBBiZMOhe/N L+cg==
X-Gm-Message-State: ALoCoQk2n1XyhokiiaQQhnmD9icWYCHQTNnC5QP5/WNTGV0hZ5LZJIiJy/3azaQGJtZhgKyvqONn
X-Received: by with SMTP id o66mr19609978ioo.86.1422299322936; Mon, 26 Jan 2015 11:08:42 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Jan 2015 11:08:22 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Ritter <>
Date: Mon, 26 Jan 2015 13:08:22 -0600
Message-ID: <>
To: Joe Hall <>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: <>
Cc: Manuel Pégourié-Gonnard <>, "" <>
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: Mon, 26 Jan 2015 19:08:49 -0000

On 26 January 2015 at 12:46, Joe Hall <> wrote:
> Wasn't the discussion in Denver of the flavor that applications will
> have to do length-hiding right if they want it to be secure so it
> doesn't make sense to do it in TLS? I'm probably mischaracterizing
> that, but I thought the outcome was more definitive than "maybe
> someone will get to it". (i.e., some thought it would be a bad idea to
> do it at all as it would be easy for applications to use it in an
> insecure manner)

Length hiding in the application will be able provide more nuanced and
context-dependent protection, no doubt.  But that doesn't mean
providing it as a feature in the protocol is without merit.
Application-specific protection is more robust against adaptive query
attacks whether the adversary is measuring response time.  But for
response times visible in passive captures, an application is usually
not going to leak enough timing information for a reasonable guess on
a single query.  (Think an application taking more or less time to
process a small image versus a larger image - the "proper" way to do
this is inside the application, and have it adjust it's processing
time accordingly to not leak timing information.)

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
 - A few of us (dkg, myself, Alfonso) were going to think about how to
do that and also consider writing a BCP on why padding is useful, when
it makes sense, and rough strategies for doing it