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.