Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC

Fedor Brunner <fedor.brunner@azet.sk> Thu, 24 March 2016 10:13 UTC

Return-Path: <prvs=0891930eb9=fedor.brunner@azet.sk>
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 5215C12D6CD for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 03:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk
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 WnE09vq_ToGN for <tls@ietfa.amsl.com>; Thu, 24 Mar 2016 03:13:16 -0700 (PDT)
Received: from smtp2.azet.sk (smtp-05-out.s.azet.sk [91.235.53.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C557512D658 for <tls@ietf.org>; Thu, 24 Mar 2016 03:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=BGdAJaUDUNa6Auvr9nLST5s0QNdGbRRZCwajQGcgfZg=; b=PBAFrJk8OBqiDxlzu+t1XUfogbCOv3Ycmy7ePVODXprjQXDiZMS9ytcX61hZceltXn3VGYhBjcDDkHaI2kf3mIEiTgO+AbrI5S+NICMCig2X8i6+G6KCX9dlWVXsZTOlnAFmDJ2ncbU1/gMBUhw8yc9VVqywsnPE8nTWU0oI0Tc=;
Received: from smtp-02-auth.e.etech.sk ([10.11.2.101] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1aj2GP-0001HH-CT for <tls@ietf.org> from <fedor.brunner@azet.sk>; Thu, 24 Mar 2016 11:13:13 +0100
Received: from 127.0.0.1 (atlantic480.us.unmetered.com [188.138.9.49]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 4D7308B for <tls@ietf.org>; Thu, 24 Mar 2016 11:13:04 +0100 (CET)
X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 4D7308B
Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk
To: tls@ietf.org
References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com>
From: Fedor Brunner <fedor.brunner@azet.sk>
Message-ID: <56F3BDAD.1040402@azet.sk>
Date: Thu, 24 Mar 2016 11:13:01 +0100
MIME-Version: 1.0
In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MailCleaner-DMARC: quarantine
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gC7mbneSdKB7hYfuPxXhI2D10uk>
Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC
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: Thu, 24 Mar 2016 10:13:18 -0000

Timothy Jackson:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves seemingly without regard to the cipher suite strength. Thus, they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key on the P256 curve. This seems odd to me, since the P256 curve obviously has a lower security strength than AES256. This seems important issue to resolve because most products (and even TLS libraries) do not allow the administrator to configure the available ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly undermining the security of your TLS connection.
> 
> Is this an intentional choice by this group for some reason that I haven’t realized yet?
> 
> How would this group feel about a proposal to address this by specifying in the 1.3 specification that implementations must ensure that the strength of the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? Perhaps an equivalency rule for the MAC might also be in order? Apologies if this is already resolved somewhere in the draft RFC. I looked but didn’t find it.
> 
> For what it’s worth, I’ve noticed OpenSSL and other implementations trying to address this by creating a “Suite B Mode”, but that seems to address a specific case but leave the generic case unresolved.
> 
> Cheers,
> 
> Tim
> 
> 
There are good reasons to combine AES256 with ECDHE on the P256 curve.

Please read
https://blog.cr.yp.to/20151120-batchattacks.html

"Bottom line: 128-bit AES keys are not comparable in security to 255-bit
elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe?
Unclear."

There is also the paper "Understanding brute force" from Daniel J.
Bernstein.
https://cr.yp.to/papers.html#bruteforce
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>