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

Colm MacCárthaigh <colm@allcosts.net> Wed, 16 March 2016 14:52 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6309D12D989 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 07:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
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 AOcRigVaFob3 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 07:52:49 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A42612D994 for <tls@ietf.org>; Wed, 16 Mar 2016 07:52:49 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id g3so64687456ywa.3 for <tls@ietf.org>; Wed, 16 Mar 2016 07:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=GXXOunv/dRHyEkPK06mjMw9v/U4GDpNbI2WwscBxbfI=; b=D46+YK04/SkUqUgnVAaqAq87RC1yA/tCheJ1cZBX4GjsgVJl7Nm6Mdy1+KSbURZ0Ub 7Kc+w+hGUsRo163ATDL8h94ZAk+R+REUCji5oG+cOj+OfWDFkd5vPUQB7hgI53DJbqGA hKao8Dxx8LrMBdgTdJKgjtsN1cL7QgQElZwmp5AfDMw5SjgK/IX9D5m27BO/6xQX+Ecr 8frTXesegRRwiRRi70H1SdRZyVvyZS82Hcp63u8V/gqlcgB+VpHWy8ooqFUaw6RrwyBm RgOkNnVacClsJMzhv7CsVENH0ixr6tS/d9TPGZvIBo2hf7kMig3xExcfy5EVqdqfCCBw 3g6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=GXXOunv/dRHyEkPK06mjMw9v/U4GDpNbI2WwscBxbfI=; b=IWZH1j/YCPyPr3L4lXlC9tmxlVgzdORLvVQre+WrjdyjGMStxXa4Vb2/U0VarEbuXm rFH2UDF9v6IReElwexvx8H736KPfgPfUg2IMUsRMman83XXa3Kgz4lppFRABdHiVCal4 o0gQoR3vNITx0qQbY8BBqKKQrdowkqZQ8p+5secQDJBXFJCyt0YpgF67Q7WX+cAlp/b9 U4/YGGE6omWSiKtr2E1G7LYHiGNOxZASISHommbJMZyACMiI1n5j8BbBP9DG6uUBgtB9 1Nr+yiDaU4OyELjh1/j3dJRS4cnJK20Uh8GB4y5UHU6l36IGMSU7WGpV5FkQyY1VHuHE rYQg==
X-Gm-Message-State: AD7BkJI9moghbi2kza0KcxOxOGkmX8VUy5gZ7mdbmr6DI9C5Y1I1tsg5kHeTjMLnfLF6Tz7fnaXFZi98fCGAgg==
MIME-Version: 1.0
X-Received: by 10.129.72.78 with SMTP id v75mr2221797ywa.78.1458139968727; Wed, 16 Mar 2016 07:52:48 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 07:52:48 -0700 (PDT)
Date: Wed, 16 Mar 2016 10:52:48 -0400
Message-ID: <CAAF6GDekw3stfYGd1q+Zzde--g5M0h9ZTWrVLVJxEwp+frQTHQ@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a114dcb02df1983052e2baa5f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/TXMrjEXZpxq7Iw6RbjKDyiw1kho>
Subject: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Mar 2016 14:52:51 -0000

This has been bugging me for a long time and I've talked to some here about
it in person, but this report;

https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upturn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf

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?

The AEAD cipher suites as-implemented are byte-for-byte mappable to
response sizes, with no padding for any kind of length hiding. This makes
passive size analysis attacks quite a lot easier than they could be (a
quick sample of wikipedia page sizes suggests that even 16 byte blocks
raise the difficulty by orders of magnitude). The search hints attack
outline in the paper may not even work with 16-byte padding. I want to
emphasize that the attack here is passive, undetectable to servers or
clients, and realistic - it's likely happening today.

On the other side of the trade-off is that the AEAD mode ciphers are not
susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago I
wrote up some detail on the Lucky13 attack:
https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13
, and my take here is that the scenario is so unrealistic that the attack
is simply impractical against TLS - even unmitigated. In any event, TLS CBC
implementations have been mitigated and patched. Here I also want to
emphasize that the attack is active - it generates lots of noisy signals -
and may never have happened.

Is it wise to make the real-world attack cost less, to mitigate the
theoretical one? I also think AEAD mode is awesome: it's how crypto should
be used, and want to give it a strong endorsement, but not at the cost of
making on-the-wire data meaningfully less secure.

At a minimum: could we agree that if a service/site is sensitive to privacy
- it's reasonable for them to prefer AES-CBC; should they be penalized in
SSL health analysis tools/reports for that configuration? it's not as
flexible or useful as the padding in TLS1.3, but it's what we have.

-- 
Colm