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

Colm MacCárthaigh <colm@allcosts.net> Wed, 16 March 2016 18:32 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 2FB5212DA70 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:32:38 -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 ebsh91thpxSm for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:32:36 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 BD98112DA08 for <tls@ietf.org>; Wed, 16 Mar 2016 11:32:35 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id g3so72655160ywa.3 for <tls@ietf.org>; Wed, 16 Mar 2016 11:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4uYGbZjFJkERYu+5rWSXYkte2Q36+WJZGJ4oANDYkpU=; b=Wjue0ZpVGUdpvS2/COWAwR65rTfxjvilLaGzvmKkoa1ig1dFud7eBOoZPP/XZ4uku3 klXzMn+Hj6uApkvWWAUIoHb9DeMfe7sFh/0M3oSCNh+IBB35n6P6nUsPYx/VTNM2OCdf wJ6zcvxADOF8qRXmN9tyjaAKGQbE+bNFU0BTsgYL9mE509bGxBNX7R+Y4+t27FbCPC3q pKBVxJiymHM7xaz4H0BKlZPX2ax+qo71cuOIZ3puxgucILGcNVxWil/TSBGXo+XR2Aa6 Pzed04aTcjndbHyU6IAgC8I9frY8xk5lUEYjpKqeKP4fpy9qMPBcCxX+WvPVxfrwUl1u xg1w==
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:date :message-id:subject:from:to:cc; bh=4uYGbZjFJkERYu+5rWSXYkte2Q36+WJZGJ4oANDYkpU=; b=d8k7OBEjEwIWah67uTErZIH/WSziW9UWa02gaXbaTXTlqpN33C/zV9TRk2BYfEua9h YsV7as2QdKTDMXQMQvD6R29UQTWuODcWuRH+I4Mp5JbKFqvte+IG9g50n6ipZBU1UO6O XnXdtrbjczAvdjWPL0/9+hmp5uX0qLwaqkiXnCOTZ8O/9vEi/fP1+Wh2IaIk4/YHbeVc HkFqqO7yTNmIdVof0pv3bzb376f2gx6bccIZPAJ19S/faY8qqSalVT90sUitbdmY5CMm Dn5l0oYDA+C4UYZzV5WUYIysaBILNyXvz0kpXm3NrvktCkZmT0zvSVhewObKrMro6saE LFXQ==
X-Gm-Message-State: AD7BkJIzRMwG6zhbIaJc1jKJgaex8BTNZYHAH7tL+Iowgn3IstFi3L0vVrl5fToGoryJmBzeWn1wfxPswpvmmw==
MIME-Version: 1.0
X-Received: by 10.13.252.197 with SMTP id m188mr2752547ywf.281.1458153154849; Wed, 16 Mar 2016 11:32:34 -0700 (PDT)
Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 11:32:34 -0700 (PDT)
In-Reply-To: <D30F5033.66E40%kenny.paterson@rhul.ac.uk>
References: <CAAF6GDekw3stfYGd1q+Zzde--g5M0h9ZTWrVLVJxEwp+frQTHQ@mail.gmail.com> <D30F5033.66E40%kenny.paterson@rhul.ac.uk>
Date: Wed, 16 Mar 2016 14:32:34 -0400
Message-ID: <CAAF6GDfsMivA_LiWK2xJgyhMTf8ygFo17MN+YkAnTN2-HV8Ryw@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: multipart/alternative; boundary=94eb2c06c240d31d71052e2ebc6d
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4ux7gGlPYYtpE4XErrIX3PEHb5U>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [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 18:32:38 -0000

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>;
wrote:
>
> Well, you know already that we disagree on this :-)
>
> For everyone else's benefit, let me say the following:
>
> - Attacks only ever get better.
>

This applies to the passive size side-channel ones too though; and we're
seeing credible evidence that they're already happening today. I think
anything we can do here to raise costs for the attackers is worthwhile.


>
> - The Lucky 13 timing signal can be amplified for DTLS using packet trains
> (see this NDSS 2012 paper for the techniques:
> http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram
> -tls).
>

That's true, but I don't think it's all that relevant to the security of
TLS as used. In general DTLS has been more vulnerable to all sorts of
active protocol level attacks because of the weaker guarantees it can
provide.

- As your blog nicely explains, AWS's s2n implementation chose to mitigate
> Lucky 13 using a bespoke solution. This code was found to be vulnerable to
> attack shortly after the code was released
> (https://eprint.iacr.org/2015/1129). The initial patch to the code was
> also insecure (https://eprint.iacr.org/2015/1241). Readers can draw their
> own conclusions from this. Mine is that even gifted programmers get TLS's
> MtE construction wrong.
>

Well as the blog also explains, at no time was s2n succeptible to a Lucky13
vulnerability. In fact; as-it-was s2n did considerably better than
alternatives widely used in production. And that's my point here; we may be
over-indexing on the issue itself. Programmers certainly get things wrong -
though in this case the decision to use the hmac() construction as it is
specified (so that it can be formally verified against the specification)
was intentional.

But I take the point that AEAD modes are harder for programmers to screw
up; and that does have value. But my experience is that folks are pretty
good about keeping software up-to-date with patches and so on, and less
good about keeping configuration settings and protocol choices safe. As we
broaden the use of AEAD, more traffic becomes more susceptible to the very
real-world attacks above, and it's a "stickier" problem that will stay in
place.

I feel strongly that going back to MtE would be a retrograde step.
>

I don't like MtE one bit, but I also don't like zero length hiding one bit.
So it's a complicated nuanced trade-off.

-- 
Colm