Re: [TLS] Safe ECC usage

Kyle Hamilton <aerowolf@gmail.com> Tue, 01 October 2013 03:36 UTC

Return-Path: <aerowolf@gmail.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 C34C121F9A10 for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 20:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.983
X-Spam-Level:
X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 AwCXcdRLHrEI for <tls@ietfa.amsl.com>; Mon, 30 Sep 2013 20:36:57 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id CED1E21F923D for <tls@ietf.org>; Mon, 30 Sep 2013 20:36:56 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id f12so6659530wgh.17 for <tls@ietf.org>; Mon, 30 Sep 2013 20:36:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MjhlFe+cN+6Nc8RiVIwBrrEN9LebN4CQeC8WIMrwKWM=; b=RfVhVl8B1MyxROSwokjSyp69X51Hx60vJOPe2OgYNpJjPawiI9rEEajGnYTXaqD2iS N2z8Qtrex3nk6WagfrHyOKirbAefLZocnMdsOmdl3+ylMtiVCARF9aSo09lg2IqoRI1j Mhoik7ZkqhBYYbc+JsyFWPU9ixTyocyPwKHp4GpIq6eZgEZpmC/ZWlpFQCrjHgGfxLY5 tWW0+Ht9GuJYvSvxtSYiV/cKOiPuPDBErm8Vw3o5ouf1pibfyZXdy2wlwgS+nR7z1yjS c7Us1bSsrIMkY2aPlpbzPCDc5M2NJ9NXneAZmdzqGkPe8jz+OjXveRwf4HDrxNod95MV IMXg==
MIME-Version: 1.0
X-Received: by 10.180.85.197 with SMTP id j5mr16634005wiz.22.1380598614633; Mon, 30 Sep 2013 20:36:54 -0700 (PDT)
Received: by 10.194.134.67 with HTTP; Mon, 30 Sep 2013 20:36:54 -0700 (PDT)
In-Reply-To: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
References: <CAPMEXDb4=BzU5JwnAFJRjdXHEa30Ara8VMbi2hZGneuKA3s0iw@mail.gmail.com> <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
Date: Mon, 30 Sep 2013 20:36:54 -0700
Message-ID: <CAPMEXDY_0mDWmNr=+DHgeWtrqA6rZ06XiLLchuB2g-G52Ebv9A@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: mrex <mrex@sap.com>
Content-Type: multipart/alternative; boundary=f46d044480b700b59104e7a5aace
Cc: "tls@ietf.org" <tls@ietf.org>
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 03:36:58 -0000

Martin,

When is the last time a purely mathematical algorithm was in fact
patentable and defensible?

Not to mention, Ed25519 is in fact a nonpatented EC signature capability,
but it is more a one-time authenticator than anything resembling a flat
signature.

Please stop being a shill for BULLRUN.

-Kyle H


On Mon, Sep 30, 2013 at 3:50 PM, Martin Rex <mrex@sap.com>; wrote:

> Kyle Hamilton wrote:
> >
> > That's all well and good, but perhaps should you try to figure out how
> your
> > functions can in fact be used in such standards as TLS without having to
> > resort to pulling hens' teeth?
> >
> > Or perhaps apply your (admittedly much better than mine) intellect to
> > figure out how to create a single public key from a single private key
> > which can be used for both signing and key derivation, thus permitting
> > consolidation of both into a single X.509 Certificate structure?  The
> lack
> > of this is in fact a major impediment to using self-signed certificates
> as
> > containers for curve25519 public keys.
>
> I currently do not see any benefit from using EC for digital signatures,
> but instead a huge amount of code, complexity and IPR issues (did you
> look at the CertiCom idea how to charge?).
>
> What I believe would be more attractive is an alternative to rfc4492
> for ECDHE_RSA based on curve25519 (and _just_ 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.
>
> -Martin
>