Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

Adam Langley <> Wed, 16 March 2016 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE9D412DA78 for <>; Wed, 16 Mar 2016 11:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6D7uW7CZfave for <>; Wed, 16 Mar 2016 11:30:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9901612DA08 for <>; Wed, 16 Mar 2016 11:30:04 -0700 (PDT)
Received: by with SMTP id w104so50815080qge.1 for <>; Wed, 16 Mar 2016 11:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=IZCPiWJ8N9auZKxFI7Qiih3Lo3ULMeNxBsEV6sTLE7k=; b=qnUv2KvUOSU6Sro/1+AFAQECUBuuXaS+x/5RNcI9EB7TnG5vcexcV2JB5RLTYrnjSF ek7Sy4k6wFd6tNG+VacmhkOe3BPO/JFCqzvujomdRauAGFQZ8s9HpnX/E4SU4rdKYrT7 fr40aA8rlMLoC0z7WS2qZAHeNkppTs5qASVZyuE6vC2Vbq0zsCHVR3dvhHv/9QpQfjBB WfUljkdKotty9+Rg3VxAtkO4g6wAnV7w8u13acDclrB2K6xywLrwTJcp0cMP1ipmTazf vMFXtItdSGI63zOaiWdD6Is8cbGCfcc5CPo5xoUkRKyzSIVMQG76q0KVSCentA4KQaxS Yajw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IZCPiWJ8N9auZKxFI7Qiih3Lo3ULMeNxBsEV6sTLE7k=; b=Gu1RBhcy95jvPfGeigHKLBWE9BmeahUJWcTcxEeDgMGn7pQZQBV/lPaPe6TAV/uURT kDilJunZ3X/Lg+yZ5B1KMHq/nReww8nvTLqy6J7mmo0cRMNtythhyjfVf/+VDRV0XRhX Ch7HFUAa74zwW9qJj1lCYadt0CaeIqtLFPYHKlzX856J39DPS7BiGgu3jKvmI5gpMyX1 AjGDMaGLIvyBAuvH+D4+8USvaF/khXJFaWA+ATSPf65OFvnk1zbNWqiBv1IXBGxcBaSd J9H2H/h7ZkKTsMRHPvspAye9YjEyP83rVXJCBDd9qpcymUNIKiGqjipA5s5FBcJV31DT Rilw==
X-Gm-Message-State: AD7BkJL6IrS3UQ7uTjbuAuHmOLTnN+UgWCKNYye5yJBJqros43IAbRkfIX1yyBvQFMFPRXx2ZgGx7Hk7W2Knaw==
MIME-Version: 1.0
X-Received: by with SMTP id r82mr7892087qha.60.1458153003643; Wed, 16 Mar 2016 11:30:03 -0700 (PDT)
Received: by with HTTP; Wed, 16 Mar 2016 11:30:03 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 16 Mar 2016 18:30:03 +0000
X-Google-Sender-Auth: OT3aMyOedaoK2FFUb_tYiAe9cJU
Message-ID: <>
From: Adam Langley <>
To: "Paterson, Kenny" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?
X-Mailman-Version: 2.1.17
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, 16 Mar 2016 18:30:07 -0000

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
<> wrote:
>>provokes me to bring it up. Here's the crux of it; is it really a
>>security win to recommend the AEAD cipher suites for TLS 1.2 users?

I'm skeptical about the benefit of padding to 16 bytes. While it does
increase the size classes in your Wikipedia example, Wikipedia pages
trigger subresource loads, which also have a size and page-to-page
navigation leaks more information. My takeaway from reading
traffic-analysis papers over the years is that countermeasures are
surprisingly difficult.

On the other hand, the CBC cipher suites are fundamentally broken,
rather slow and, in an attempt to fix them, are now very complex. So I
don't believe that the benefits of padding to 16 bytes comes close to
justifying the use of the CBC modes. Over the coming years I hope that
CBC modes are killed off in the same fashion that RC4 now has been in
several browsers.

Padding at the application-level (e.g. HTTP) is probably the easiest,
reasonable place to add padding (if there's a scheme with solid
justification). Sure, one doesn't get "automatic" padding that using
CBC modes might (somewhat) get you, but I still don't think CBC is a
good tradeoff.