[TLS] Using ECC Brainpool curves with TLS

Johannes Merkle <johannes.merkle@secunet.com> Fri, 06 July 2012 08:43 UTC

Return-Path: <Johannes.Merkle@secunet.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 3E6CB21F86D1 for <tls@ietfa.amsl.com>; Fri, 6 Jul 2012 01:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 HlHPIlUHB-N3 for <tls@ietfa.amsl.com>; Fri, 6 Jul 2012 01:43:24 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0452321F86D5 for <tls@ietf.org>; Fri, 6 Jul 2012 01:43:23 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 6B65B1A008F; Fri, 6 Jul 2012 10:43:38 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 578C51A008E; Fri, 6 Jul 2012 10:43:34 +0200 (CEST)
Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jul 2012 10:43:27 +0200
Message-ID: <4FF6A52F.1030308@secunet.com>
Date: Fri, 06 Jul 2012 10:43:27 +0200
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Jul 2012 08:43:28.0041 (UTC) FILETIME=[69E17990:01CD5B53]
Subject: [TLS] Using ECC Brainpool curves with 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: Fri, 06 Jul 2012 08:43:25 -0000

Hello all,

in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile,
support for these ECC Brainpool Curves has been included in some crypto libraries as openssl (recently) and crypto++.
However, in order to use the Brainpool Curves with TSL (for authentication and/or key agreement), still some
specifications and IANA registry updates are needed. Therefore, an RFC specifying the usage of the ECC Brainpool Curves
with TLS has to be written.

In order to go forward with this, we would like to discuss some questions and potential issues. We would appreciate any
feedback on the following.

[Question 1] According to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be
shepherded by the TLS WG. Therefore, our first and most important question is: Is the WG willing to shepherd this RFC?

[Question 2] What category will be preferred for this RFC, Standards Track or Informational RFC?

[Question 3] Actually, we also plan to prepare analogous specifications for IKE, so an option may be to write a common
RFC for TLS and IKE analogously to RFC 5114. Would this be a good idea, in particular as this would imply shepherding by
two WGs, or would it be better to prepare separate RFCs for IKE and TLS?

[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one
being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of
them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the
implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course,
this doubles the number of number assignments. Does anyone consider this a problem?

[Question 5] No IANA registries are required for DTLS. However, authors have to specify whether new identifiers for TLS
are suitable for DTLS as well. This should be done for the ECC Brainpool curves. Any comments on this?

Johannes
--
Johannes Merkle
secunet Security Networks AG
johannes.merkle@secunet.com
www.secunet.com