Re: [TLS] Curve25519 in TLS

Simon Josefsson <simon@josefsson.org> Wed, 11 September 2013 17:13 UTC

Return-Path: <simon@josefsson.org>
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 4855521F9950 for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 10:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 uPrPIc9MOzrP for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 10:13:30 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 3834C21F8616 for <tls@ietf.org>; Wed, 11 Sep 2013 10:13:14 -0700 (PDT)
Received: from latte.josefsson.org ([38.111.151.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8BHCcjO000701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Sep 2013 19:12:42 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Rob Stradling <rob.stradling@comodo.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>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130911:tls@ietf.org::01n6l80lrWdj6XCy:Fu5S
X-Hashcash: 1:22:130911:code@funwithsoftware.org::IiuN+0cly6SCSmd5:K1Yb
X-Hashcash: 1:22:130911:rob.stradling@comodo.com::DhZ5y69jgTfDVS7G:Ezl0
Date: Wed, 11 Sep 2013 10:12:31 -0700
In-Reply-To: <522ED9A7.7080802@comodo.com> (Rob Stradling's message of "Tue, 10 Sep 2013 09:34:47 +0100")
Message-ID: <87fvtbi8ow.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: 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: Wed, 11 Sep 2013 17:13:31 -0000

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?  Performance is less critical there than for ECDH, but
if you or someone else has numbers indicating X.509 signature
verification being a performance bottle neck I would be convinced
otherwise.  There could be other reasons than performance though, but
they should be articulated and examined.

RFC 5639 contains a lot of things, is there anything other than the OID
and PKIX usage you think is relevant for Curve25519?

/Simon