Re: [TLS] Curve25519 in TLS

Yoav Nir <ynir@checkpoint.com> Thu, 12 September 2013 13:59 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 27C0911E8194 for <tls@ietfa.amsl.com>; Thu, 12 Sep 2013 06:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.768
X-Spam-Level:
X-Spam-Status: No, score=-9.768 tagged_above=-999 required=5 tests=[AWL=0.830, 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 o9hQ6HIapY6C for <tls@ietfa.amsl.com>; Thu, 12 Sep 2013 06:59:23 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA3611E8117 for <tls@ietf.org>; Thu, 12 Sep 2013 06:59:00 -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 r8CDwSGo006162; Thu, 12 Sep 2013 16:58:28 +0300
X-CheckPoint: {5231C884-15-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 12 Sep 2013 16:58:28 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Rob Stradling <rob.stradling@comodo.com>
Thread-Topic: [TLS] Curve25519 in TLS
Thread-Index: AQHOrZiFYK+MfjUPYEadQ22tq6Y9cJm+c7uAgAJVsFaAARbTgIAAEpYA
Date: Thu, 12 Sep 2013 13:58:28 +0000
Message-ID: <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com>
References: <a84d7bc61003011620i66fc7dfdre62b548fdd5ef7dd@mail.gmail.com> <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com>
In-Reply-To: <5231B8ED.7040301@comodo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.32]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C18238E8BF69E742AADBC2C039A864D7@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Simon Josefsson <simon@josefsson.org>, Patrick Pelletier <code@funwithsoftware.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Curve25519 in TLS
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: Thu, 12 Sep 2013 13:59:42 -0000

On Sep 12, 2013, at 3:51 PM, Rob Stradling <rob.stradling@comodo.com>; wrote:

> On 11/09/13 18:12, Simon Josefsson wrote:
>> Rob Stradling <rob.stradling@comodo.com>; writes:
>> 
>>> Simon, thanks for creating this draft.
>>> 
>>> draft-merkle-tls-brainpool-04 (on which you've based this new draft) says:
>>>    "While the ASN.1 object identifiers
>>>    defined in [RFC5639] already allow usage of the ECC Brainpool curves
>>>    for TLS (client or server) authentication through reference in X.509
>>>    certificates according to [RFC3279] and [RFC5480] , their negotiation
>>>    for key exchange according to [RFC4492] requires the definition and
>>>    assignment of additional NamedCurve IDs."
>>> 
>>> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
>>> to be used for key exchange.  But what about "(client or server)
>>> authentication through reference in X.509 certificates..."?
>>> 
>>> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
>>> create one?  Or could we simply define some new ASN.1 Object
>>> Identifiers in your draft?
>> 
>> Yes perhaps.  What would the purpose of using Curve25519 in X.509
>> certificates be?
> 
> I just thought it seemed like a logical thing to do.  We can already do ECDHE-ECDSA using the NIST curves for both keys in certs and for key exchange, so why wouldn't we allow Curve25519 to be used for both purposes?
> 
> Unless NIST can prove that their curves aren't backdoored, I think it's likely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA without touching the NIST curves at all.  What options do they have?

Umm, the brainpool curves are available.

Also, I don't get why performance would be less critical than that of ECDHE. In a full handshake, you do both an ECDSA signature and the ECDHE operations. Why would one matter while the other does not?

Yoav