idnits 2.17.1 draft-josefsson-tls-curve25519-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 114: '...tHello extension SHOULD also advertise...' RFC 2119 keyword, line 116: '... MUST NOT select an ECDHE_ECDSA ciph...' RFC 2119 keyword, line 121: '... Private keys MUST be selected as specified in [Curve25519]. That is,...' -- The draft header indicates that this document updates RFC4492, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4492, updated by this document, for RFC5378 checks: 1998-03-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 8, 2014) is 3754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Updates: 4492 (if approved) January 8, 2014 5 Intended status: Informational 6 Expires: July 12, 2014 8 Elliptic Curve Diffie-Hellman Key Agreement using Curve25519 for 9 Transport Layer Security (TLS) 10 draft-josefsson-tls-curve25519-02 12 Abstract 14 This document specifies the use of Curve25519 for key exchange in the 15 Transport Layer Security (TLS) protocol. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 12, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 In [Curve25519], a new elliptic curve function for use in 52 cryptographic applications was specified. Curve25519 is a Diffie- 53 Hellman function designed with performance and security in mind. 55 [RFC4492] defines the usage of elliptic curves for authentication and 56 key agreement in TLS 1.0 and TLS 1.1, and these mechanisms are also 57 applicable to TLS 1.2 [RFC5246]. The use of ECC curves for key 58 exchange requires the definition and assignment of additional 59 NamedCurve IDs. This document specify that value for Curve25519, as 60 well as the minor changes in key selection and representation that 61 are required to accomodate for Curve25519's slightly different 62 nature. 64 This document only describes usage of Curve25519 for ephemeral key 65 exchange (ECDHE), not for use with long-term keys embedded in PKIX 66 certificates (ECDH_ECDSA and ECDH_ECDSA). 68 Curve25519 is not directly suitable for authentication, and thus not 69 applicable for signing of e.g. PKIX certificates. See draft- 70 josefsson-eddsa-ed25519 for a parallel effort. 72 2. Data Structures and Computations 74 [RFC4492] and related standards [SEC1] define an elliptic curve over 75 GF(p) as the set of solutions of the equation y^2 = x^3 + a x + b 76 (commonly referred to as a short Weierstrass equation) with both x 77 and y in GF(p), plus the point at infinity. For each curve, a point 78 G is fixed, generating a subgroup of large (prime) order N. 80 The Diffie-Hellman key exchange is then defined as follows: each 81 party generates a random number 1 <= d < N (the private key), 82 computes Q = d G (the public key). The parties exchange their public 83 keys and compute the shared secret as Z = d Q_peer. 85 [RFC4492] defines formats for representing public keys during the 86 exchange, and extensions for negotiating the format used by each 87 party and the underlying curve used by both parties. 89 While retaining the same overall structure for the Diffie-Hellman key 90 exchange, Curve25519 makes some changes to the way the curve equation 91 is presented, private keys are selected and public keys exchanged, in 92 order to ease secure and efficient implementations. 94 The following subsections describe the differences between using 95 Curve25519 and the curves defined by RFC 4492 for key exchange in 96 TLS. 98 2.1. Group negotiation and new NamedCurve type 100 Curve negotiation is the same for Curve25519 as for other curves, but 101 is restricted to using the named_curve type in the ServerKeyEchange 102 message: the explicit_prime type is only suited to curves in short 103 Weierstrass form. This document adds a new NamedCurve value for 104 Curve25519 as follows. 106 enum { 107 curve25519(TBD1), 108 } NamedCurve; 110 The curve is suitable for use with DTLS [RFC6347]. 112 Since Curve25519 is not designed to be used in signatures, clients 113 who offer ECDHE_ECDSA ciphersuites and advertise support Curve25519 114 in the elliptic_curves ClientHello extension SHOULD also advertise 115 support for at least one other curve, suitable for ECDSA. Servers 116 MUST NOT select an ECDHE_ECDSA ciphersuite if the only common curve 117 is Curve25519. 119 2.2. Private key generation 121 Private keys MUST be selected as specified in [Curve25519]. That is, 122 private keys are 255-bits numbers with the following properties: the 123 most significant bit (bit 254) is set, and the three least 124 significants bits are cleared; the remaining bits (3 to 253 included) 125 are chosen uniformly at random. 127 2.3. Public key representation 129 For ECDHE, public keys need to be transmitted in the 130 ServerKeyExchange and ClientKeyExchange messages, both of which 131 encode it as follows. 133 struct { 134 opaque point <1..2^8-1>; 135 } ECPoint; 137 For short Weierstrass curves, the contents of ECPoint.point are 138 defined by X9.62. For Curve25519, the ECpoint structure is the same, 139 but the contents of ECPoint.point are encoded and interpreted as 140 follows: each peer's public key is a number between 0 and 2^255 - 20 141 included, and ECPoint.point contains the 32 bytes string representing 142 this number in big endian convention. (The receiving party can 143 accept any 32 bytes string, interpreted as a 256 bits number, as 144 public key: by design, no validation is needed.) 145 Note that ECPoint.point differs from the definition of public keys in 146 [Curve25519] in two ways: (1) the byte-ordering is big-endian, wich 147 is more uniform with how big integers are represented in TLS, and (2) 148 there is an additional length byte (so ECpoint.point is actually 33 149 bytes), again for uniformity (and extensibility). 151 Since only one point format can be used with Curve25519, which is 152 distinct from the formats used by short Weierstrass curves, the 153 contents of the "Supported Point Formats" extension is irrelevant for 154 this curve. Peers do not need to advertise support for the above 155 point format in any way (nor check that the orther party supports it) 156 when planning to use Curve25519 for key agreement: support for 157 Curve25519 implies support for the above point format, which is tied 158 to it. 160 2.4. Shared secret computation 162 As in the standard Elliptic Curve Diffie-Hellman protocol [SEC1], 163 each party computes the shared secret by multiplying the peer's 164 public value (seen as a point on the curve) by its own private value, 165 except that in the case of Curve25519, only the x coordinate is 166 computed. This is merely an internal detail since [RFC4492] 167 specifies that only the x coordinate is used as the premaster secret 168 anyway. 170 Again, in line with [RFC4492] and as a departure from the convention 171 chosen in [Curve25519], the x coordinate is converted to a bytes 172 string using big endian order. As in [RFC4492], leading zeros are 173 preserved, so the premaster secret is always a 32 bytes string with 174 Curve25519. 176 3. IANA Considerations 178 IANA is requested to assign numbers for Curve25519 listed in 179 Section 2.1 to the Transport Layer Security (TLS) Parameters registry 180 EC Named Curve [IANA-TLS] as follows. 182 +-------+-------------+---------+-----------+ 183 | Value | Description | DTLS-OK | Reference | 184 +-------+-------------+---------+-----------+ 185 | TBD1 | curve25519 | Y | This doc | 186 +-------+-------------+---------+-----------+ 188 Table 1 190 4. Security Considerations 191 The security considerations of [RFC5246] and most of the security 192 considerations of [RFC4492] apply accordingly. 194 Curve25519 was specifically designed so that secure, fast 195 implementations are easier to produce. In particular, no validation 196 of public keys is required, and point multiplication (using only the 197 x coordinate) can be efficiently [EFD] computed with a Montgomery 198 ladder using a constant number of operations (since the actual bit 199 length of the private key is fixed), which avoids a number of side- 200 channel attacks. However, in the fight against side-channel leaks, 201 implementors should also pay attention to the following points: 203 1. In the Montgomery ladder, avoid branches depending on secret data 204 (the individual bits of the secret key); 206 2. In the same place, avoid memory access patterns dependant on 207 secret data; 209 3. Either avoid data-dependant branches and memory access patterns 210 in the underlying field arithmetic (that is, the bignum 211 arithmetic, including the mod 2^255-19 operation) or randomize 212 projective (that is, x/z) coordinates by multiplying both x and z 213 with the same 256-bit value, chosen at random. 215 Some of the curves defined in [RFC4492], namely all whose name ends 216 with r1 or r2, have been advertised as pseudo-randomly chosen, but 217 the lack of verifiability of the seeds has raised concerns that the 218 those curves might be weaker than expected aginst some attackers. 219 The Koblitz curves (those whose name end with k1) of [RFC4492] do not 220 suffer from this problem, but are char2 curves and there seems to be 221 a consensus that curves over prime fields are a safer bet against 222 future progress in discrete log computation. The Brainpool curves 223 [RFC7027] are prime curves generated in a fully verifiable pseudo- 224 random way to avoid manipulation concerns, but do not perform as well 225 due to the use of pseudo-random primes. Curve22519 is also chosen in 226 a fully verifiable way, but offers better performances (better than 227 the curves form [RFC4492]) while facilitating secure implementations 228 as mentioned above. See also [SafeCurves]. 230 5. References 232 5.1. Normative References 234 [Curve25519] 235 Bernstein, J., "Curve25519: new Diffie-Hellman speed 236 records", WWW 237 http://cr.yp.to/ecdh/curve25519-20060209.pdf, February 238 2006. 240 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 241 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 242 for Transport Layer Security (TLS)", RFC 4492, May 2006. 244 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 245 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 247 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 248 Security Version 1.2", RFC 6347, January 2012. 250 5.2. Informative References 252 [IANA-TLS] 253 Internet Assigned Numbers Authority, "Transport Layer 254 Security (TLS) Parameters", . 257 [SafeCurves] 258 Bernstein, D. and T. Lange, "SafeCurves: choosing safe 259 curves for elliptic-curve cryptography.", January 2014, 260 . 262 [EFD] Bernstein, D. and T. Lange, "Explicit-Formulas Database: 263 XZ coordinates for Montgomery curves", January 2014, 264 . 267 [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography 268 (ECC) Brainpool Curves for Transport Layer Security 269 (TLS)", RFC 7027, October 2013. 271 [SEC1] Certicom Research, , "Standards for Efficient Cryptography 272 (SEC) 1", September 2000. 274 Appendix A. Test vectors 276 This section provides some test vectors for example Diffie-Hellman 277 key exchanges using Curve25519. The following notations are used: 279 d_A the secret key of party A 281 x_A the public key of party A 283 d_B the secret key of party B 285 x_B the public key of party B 286 x_S the shared secret that results from completion of the Diffie- 287 Hellman computation, i.e., the hex representation of the pre- 288 master secret. 290 The field elements x_A, x_B, and x_S are represented as hexadecimal 291 values using the FieldElement-to-OctetString conversion method 292 specified in [SEC1]. 294 d_A = 5AC99F33632E5A768DE7E81BF854C27C46E3FBF2ABBACD29EC4AFF51 295 7369C660 296 d_B = 47DC3D214174820E1154B49BC6CDB2ABD45EE95817055D255AA35831 297 B70D3260 298 x_A = 057E23EA9F1CBE8A27168F6E696A791DE61DD3AF7ACD4EEACC6E7BA5 299 14FDA863 300 x_B = 6EB89DA91989AE37C7EAC7618D9E5C4951DBA1D73C285AE1CD26A855 301 020EEF04 302 x_S = 61450CD98E36016B58776A897A9F0AEF738B99F09468B8D6B8511184 303 D53494AB 305 Author's Address 307 Simon Josefsson 308 SJD AB 310 Email: simon@josefsson.org