Re: [TLS] Obstacles to standardizing ECC in TLS
Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 10 June 2014 07:39 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307BC1A0424 for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 00:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 dyI-Ftd0DhVX for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 00:39:38 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADBD1A023C for <tls@ietf.org>; Tue, 10 Jun 2014 00:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1402385977; x=1433921977; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=GllN6V3apIxLw+U96lmu6V348S880qOFRe0OBPQP+1Q=; b=gDQI/SiE1vpnMdazCXHcbo5rMqEc+ww+o3LIV3WLj0SHnpWRvNj6W6Lm tUmMuHNxjlkFu23CIeVQuUza2cCXRcxaloeKSqS/fp+I/wC+ebRlEUx19 AuUIL81uOBCHJnQJ1iPMLkuqoKg9vC6BHl4v5nhHCBM6xPsFsp+QePqN0 E=;
X-IronPort-AV: E=Sophos;i="4.98,1007,1392116400"; d="scan'208";a="257626718"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Jun 2014 19:39:35 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 19:39:35 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Obstacles to standardizing ECC in TLS
Thread-Index: Ac+Efx/fzHKqeHQmRFyR7lSFuQLAWA==
Date: Tue, 10 Jun 2014 07:39:34 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C738DEC4D3D@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PgYxsKshm_hKfE-nB1g_yc6UEQE
Subject: Re: [TLS] Obstacles to standardizing ECC in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Jun 2014 07:39:42 -0000
Eric Rescorla <ekr@rtfm.com> writes: >As you no doubt know, TLS already specifies a number of ECC-based cipher >suites (RFC 4492 and following) and there are interoperable implementations >of many of these cipher suites. The two relevant questions for the TLS WG >seem to me to be: > >[...] There are actually more issues than that with ECC, see http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-05 for details: [3] provides an extremely flexible, and by extension extremely complex means of specifying a large number of options involving the use of ECC algorithms for [2]. As such the "cipher suites" in [3] aren't suites in the conventional TLS sense but more an indication of intent to negotiate a Chinese menu, with details to be decided on later via various TLS extensions and parameter settings. This makes deciding on a particular suite nondeterministic, since later parameter choices and settings can negate the initial "cipher suite" choice, requiring returning to the suite list to try with another Chinese-menu suite in the hope that later parameter choices allow it to be used. In practice no currently deployed implementation actually does this, either dropping the connection or aborting the handshake with a handshake-failure if the expected parameters aren't present throughout the various locations in the TLS handshake in which ECC parameters can be specified. This means that establishing a TLS connection using ECC often requires trial-and-error probing to ascertain what the other side is expecting to see before a connection can be established. Experience with deployed implementations indicates that all of them appear to implement a common subset of fixed ECC parameters that work in all cases (alongside the more obscure options), representing a de facto profile of standard cipher suites rather than Chinese-menu selection options. For example one widely-used implementation didn't send out TLS ECC extensions and yet other implementations had no problems interoperating with it, indicating that what this document specifies is already a de facto profile of implementations. This document standardises this de facto usage by defining a small number of standard ECC cipher suites with unambiguous parameters and settings. Peter.
- [TLS] Obstacles to standardizing ECC in TLS Watson Ladd
- Re: [TLS] Obstacles to standardizing ECC in TLS Eric Rescorla
- Re: [TLS] Obstacles to standardizing ECC in TLS Salz, Rich
- Re: [TLS] Obstacles to standardizing ECC in TLS Peter Gutmann
- Re: [TLS] Obstacles to standardizing ECC in TLS Watson Ladd