Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

Dr Stephen Henson <lists@drh-consultancy.co.uk> Sat, 11 January 2014 17:28 UTC

Return-Path: <lists@drh-consultancy.co.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307391AE085 for <tls@ietfa.amsl.com>; Sat, 11 Jan 2014 09:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUX023PCIedJ for <tls@ietfa.amsl.com>; Sat, 11 Jan 2014 09:28:36 -0800 (PST)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA01ADF46 for <tls@ietf.org>; Sat, 11 Jan 2014 09:28:35 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:34145 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1W22M8-0002rL-6u (return-path <lists@drh-consultancy.co.uk>); Sat, 11 Jan 2014 17:28:20 +0000
Message-ID: <52D17F30.1090008@drh-consultancy.co.uk>
Date: Sat, 11 Jan 2014 17:28:16 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
References: <87eh4e7a2y.fsf@latte.josefsson.org>
In-Reply-To: <87eh4e7a2y.fsf@latte.josefsson.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 11 Jan 2014 17:28:38 -0000

On 11/01/2014 16:32, Simon Josefsson wrote:
> 
> 2) Does description of private/public key representation and computation
>    of shared secret belong in draft-josefsson-tls-curve25519?  It has to
>    be somewhere, I believ, but possibly this could go into
>    draft-ladd-safecurves, or some other generic document, unless there
>    are TLS-specific aspects.  Insight into this would be appreciated.
> 

A comment on the following paragraph:

   This document only describes usage of additional curves for ephemeral
   key exchange (ECDHE), not for use with long-term keys embedded in
   PKIX certificates (ECDH_ECDSA and ECDH_ECDSA).  This is because
   Curve25519 is not directly suitable for authentication with ECDSA,
   and thus not applicable for signing of e.g.  PKIX certificates.  See
   draft-josefsson-eddsa-ed25519 for a parallel effort.

Although the curves are not directly suitable for authentication this doesn't
actually matter because the certificate doesn't have to be signed using the same
curve or indeed the same algorithm. So it would (for example) permit a
certificate containing a curve25519 key signed by a CA using a Brainpool curve
(or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that
would require a standard for the use of curve25519 in certificates which
currently doesn't exist.

Having said that the static ECDH ciphersuites are rarely used and don't offer
forward secrecy.

IMHO a discussion of private/public key format should be in a separate document
which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys
and SubjectPublicKeyInfo for public keys). That would enable the use of
curve25519 (and other curves) in a wider range of applications, not just TLS.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.