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

Timothy Jackson <tjackson@mobileiron.com> Wed, 23 March 2016 00:38 UTC

Return-Path: <tjackson@mobileiron.com>
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 4C84912D5F8 for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 17:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.onmicrosoft.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 CA5KkWdiGFsu for <tls@ietfa.amsl.com>; Tue, 22 Mar 2016 17:38:16 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0088.outbound.protection.outlook.com [65.55.169.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7470A12D5EC for <tls@ietf.org>; Tue, 22 Mar 2016 17:38:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W9b0rUIRoewRVQH7VWaF/CLVStg3WxAnDVa3GPb5/GI=; b=memRQq3OJGd4IDrET7cwzjM0qEgQi9sJ9NYaCvrXmc1WEb4g2kS2Syt8JLLxjlSieSNBdVrRoFfDl+W96KgFVngn+2NLpaTmy51+OOkoxYd0nTfbB7awIdkt5oCAZ6DLX1/CzO2XhmTheeY9r/Hlv6YhvlvtclyabsynlDjoovg=
Received: from CY1PR10MB0441.namprd10.prod.outlook.com (10.163.89.27) by CY1PR10MB0443.namprd10.prod.outlook.com (10.163.89.29) with Microsoft SMTP Server (TLS) id 15.1.443.12; Wed, 23 Mar 2016 00:38:14 +0000
Received: from CY1PR10MB0441.namprd10.prod.outlook.com ([10.163.89.27]) by CY1PR10MB0441.namprd10.prod.outlook.com ([10.163.89.27]) with mapi id 15.01.0443.015; Wed, 23 Mar 2016 00:38:14 +0000
From: Timothy Jackson <tjackson@mobileiron.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Ensuring consistent strength across certificate, ECDHE, cipher, and MAC
Thread-Index: AQHRhJxIvdQqc8JxV0CUtKcN/21N7g==
Date: Wed, 23 Mar 2016 00:38:13 +0000
Message-ID: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mobileiron.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [198.61.62.10]
x-ms-office365-filtering-correlation-id: 750f7032-0e9e-421f-e41c-08d352b36b33
x-microsoft-exchange-diagnostics: 1; CY1PR10MB0443; 5:jPpKL62aaNEIynqGofNY2TQtCRlPHHRSKopu6XC74lUSXjh+rkO5lqkASahZ4vVKxDQCHEpKNKs7LcD4hmM4xiga+lmxLpJiOBfLg3rNOwiT3YDri3Q40n5OVMrEL/hBbs9gDklB6YR0DyQwcaksSg==; 24:T56eQuF+2WaxDT4HY8v/YFByPgko5cr6QpGuTTklOrlYiYfewZcU2mjC4StJSxXQ1yZHkkuNR9apyG9MspQUjPzNBd/67oqUvZMjvWEmgjE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR10MB0443;
x-microsoft-antispam-prvs: <CY1PR10MB044303D30C69D5BC1E89A513AA810@CY1PR10MB0443.namprd10.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR10MB0443; BCL:0; PCL:0; RULEID:; SRVR:CY1PR10MB0443;
x-forefront-prvs: 08902E536D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(1730700002)(3280700002)(3660700001)(54356999)(50986999)(92566002)(2501003)(106116001)(450100001)(10400500002)(81166005)(102836003)(6116002)(586003)(3846002)(99286002)(2900100001)(5008740100001)(33656002)(1096002)(110136002)(107886002)(1220700001)(561944003)(2906002)(189998001)(82746002)(2351001)(77096005)(11100500001)(5004730100002)(86362001)(36756003)(87936001)(66066001)(83716003)(16236675004)(122556002)(5640700001)(5002640100001)(229853001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR10MB0443; H:CY1PR10MB0441.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_97CC494EFB134A6B882480CF2C7A76BFmobileironcom_"
MIME-Version: 1.0
X-OriginatorOrg: mobileiron.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 00:38:13.9620 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR10MB0443
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/v33pKcOl2qm7gPaRTGQLJYo4ZWA>
Subject: [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: Wed, 23 Mar 2016 00:38:19 -0000

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