Re: [TLS] Safe ECC usage

Yoav Nir <ynir@checkpoint.com> Tue, 01 October 2013 05:14 UTC

Return-Path: <ynir@checkpoint.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 707C821F9A44 for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 22:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.383
X-Spam-Level:
X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QXNti+EblbG for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 22:14:19 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 251DE21F9A6C for <tls@ietf.org>; Mon, 30 Sep 2013 22:14:18 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r915E9G9007390; Tue, 1 Oct 2013 08:14:09 +0300
X-CheckPoint: {524A5A21-13-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 08:14:09 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "<mrex@sap.com>" <mrex@sap.com>
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0om0uHYDyqy0CSy5O2MDQzFJncJGEAgAKSogCAAGtCAA==
Date: Tue, 01 Oct 2013 05:14:09 +0000
Message-ID: <F4AD70C9-2988-4FE2-B4BC-D9E59052FBC8@checkpoint.com>
References: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
In-Reply-To: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.43]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <A2CAF956F4530C49BED1B80C043DADC1@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 01 Oct 2013 05:14:25 -0000

On Oct 1, 2013, at 1:50 AM, Martin Rex <mrex@sap.com> wrote:

> 
> I currently do not see any benefit from using EC for digital signatures,

Other than certificate size and the speed of making those calculations?  Really, try "openssl speed rsa2048 ecdsap256" on any Linux or Mac machine.

> but instead a huge amount of code, complexity and IPR issues (did you
> look at the CertiCom idea how to charge?).

Yes, I have: "If the standard is adopted, Patent Holder will not assert any claims of any patents owned or controlled by the Patent Holder against any party for making, using, selling importing or offering for sale a product that implements the Standard…" (weird capitalization theirs, not mine)

Also, there's RFC 6090 on how you can do all the ECC operations with 1994 technology.

Also, public CAs, a notoriously careful bunch, have started issuing ECC certs, all browsers have ECC ciphersuites as does OpenSSL and others. Clearly the market is not afraid of the IPR issue.

> What I believe would be more attractive is an alternative to rfc4492
> for ECDHE_RSA based on curve25519 (and _just_ curve25519),

IANAL and neither are you. What makes you think that the IPR issues apply to P-256 more than they do to Curve25519?

> i.e.
> a small number of new cipher suites and an additional ClientKeyExchange
> and ServerKeyExchange variant specifically tailord for curve25519, so
> that there are real benefits to a full-blown and generic rfc4492 TLS EC
> crypto.

ECDHE_RSA is slower than plain RSA. ECDHE_ECDSA is faster. Once you've dipped your toe in the ECC pool, there's no reason not to have it in the signature as well.

Yoav