RFC 7027

Internet Engineering Task Force (IETF) J. Merkle
Request for Comments: 7027 secunet Security Networks
Updates: 4492 M. Lochter
Category: Informational BSI
ISSN: 2070-1721 October 2013 Elliptic Curve Cryptography (ECC) Brainpool Curves
for Transport Layer Security (TLS)
Abstract
This document specifies the use of several Elliptic Curve
Cryptography (ECC) Brainpool curves for authentication and key
exchange in the Transport Layer Security (TLS) protocol.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7027.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Test vectors for a Diffie-Hellman key exchange using these elliptic
curves are provided in Appendix A.
3. IANA Considerations
IANA has assigned numbers for the ECC Brainpool curves listed in
Section 2 in the "EC Named Curve" [IANA-TLS] registry of the
"Transport Layer Security (TLS) Parameters" registry as follows:
+-------+-----------------+---------+-----------+
| Value | Description | DTLS-OK | Reference |
+-------+-----------------+---------+-----------+
| 26 | brainpoolP256r1 | Y | RFC 7027 |
| 27 | brainpoolP384r1 | Y | RFC 7027 |
| 28 | brainpoolP512r1 | Y | RFC 7027 |
+-------+-----------------+---------+-----------+
Table 14. Security Considerations
The security considerations of [RFC5246] apply to the ECC Brainpool
curves described in this document.
The confidentiality, authenticity, and integrity of the TLS
communication is limited by the weakest cryptographic primitive
applied. In order to achieve a maximum security level when using one
of the elliptic curves from Table 1 for authentication and/or key
exchange in TLS, the key derivation function; the algorithms and key
lengths of symmetric encryption; and message authentication (as well
as the algorithm, bit length, and hash function used for signature
generation) should be chosen according to the recommendations of
[NIST800-57] and [RFC5639]. Furthermore, the private Diffie-Hellman
keys should be selected with the same bit length as the order of the
group generated by the base point G and with approximately maximum
entropy.
Implementations of elliptic curve cryptography for TLS may be
susceptible to side-channel attacks. Particular care should be taken
for implementations that internally transform curve points to points
on the corresponding "twisted curve", using the map (x',y') = (x*Z^2,
y*Z^3) with the coefficient Z specified for that curve in [RFC5639],
in order to take advantage of an efficient arithmetic based on the
twisted curve's special parameters (A = -3). Although the twisted
curve itself offers the same level of security as the corresponding
random curve (through mathematical equivalence), an arithmetic based
on small curve parameters may be harder to protect against side-

Appendix A. Test Vectors
This section provides some test vectors for example Diffie-Hellman
key exchanges using each of the curves defined in Table 1. The
following notation is used in the subsequent sections:
d_A: the secret key of party A
x_qA: the x-coordinate of the public key of party A
y_qA: the y-coordinate of the public key of party A
d_B: the secret key of party B
x_qB: the x-coordinate of the public key of party B
y_qB: the y-coordinate of the public key of party B
x_Z: the x-coordinate of the shared secret that results from
completion of the Diffie-Hellman computation, i.e., the hex
representation of the pre-master secret
y_Z: the y-coordinate of the shared secret that results from
completion of the Diffie-Hellman computation
The field elements x_qA, y_qA, x_qB, y_qB, x_Z, and y_Z are
represented as hexadecimal values using the FieldElement-to-
OctetString conversion method specified in [SEC1].