Re: [TLS] Safe ECC usage

mrex@sap.com (Martin Rex) Tue, 01 October 2013 13:40 UTC

Return-Path: <mrex@sap.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 4A1A911E8394 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 06:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.186
X-Spam-Level:
X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0PnFvNBdx+uC for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 06:40:16 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6B11E8229 for <tls@ietf.org>; Tue, 1 Oct 2013 06:38:28 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r91DcJMb015194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 15:38:20 +0200 (MEST)
In-Reply-To: <F4AD70C9-2988-4FE2-B4BC-D9E59052FBC8@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
Date: Tue, 01 Oct 2013 15:38:19 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
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
Reply-To: mrex@sap.com
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 13:40:21 -0000

Yoav Nir wrote:
> 
> 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.

openssl 1.0.1c x86_64 tells me ecdsap256 is 10x faster than rsa2048 for
signing and 10x slower than rsa2048 for verifying.

So there would be a penalty for EC signatures on certificate chains,
CRLs, OCSP and whathaveyou.

ECDH with curve25519 could be made a small code change, local to TLS,
and affecting _NONE_ of the stuff that deals with X.509 certificates.
And you need only one server certificate (RSA-2048) for everything.

> 
> > 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)

They want to charge EC cert issuers (CAs) for issuing EC certs.
The use of ECDHE with parameters authenticated by RSA certs would be
royalty free.


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

Our current crypto codebase as well as the PKIX codebase is EC-free,
and FIPS 140-2 certified.

The amount of code necessary to implement EC (crypto, PKIX, rfc4492)
is significant, and without any substantial benefits, the lid of that
can is probably not going to be reopened soon (~3-5 years).


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

CertiCom intends to charge for X.509 certs.
Don't use it for signing.

> 
> > 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.

What openssl-1.0.1c says, ECDHE_DSA is about par.

Maybe there should be a middle-ground between RSA and ECDHE_RSA.
Why is it OK for the RSA ciphersuites to perform a time-based validation
of the Server certificate, but not OK to perform a time-based validation
of the signature on the (EC)DH parameters?

>From the performance perspective, the ration of TLS session resumes
vs TLS full handshakes on a server should be 10:1 or better, otherwise
something is going terribly wrong with either the servers session cache
or the client's session caching strategy.


>
> Once you've dipped your toe in the ECC pool, there's no reason
> not to have it in the signature as well.


We haven't dipped our toe yet, and the complexity around it is certainly
no motivator to consider adding this through software maintenance.


-Martin